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10.0  FEDERAL  CONVENTIONS  FOR 
USING  ASC  XI 2  TRANSACTION 
SETS 

This  part  of  the  Federal  Implementation  Guidelines  defines  the 
Federal  transaction  set  conventions.  It  includes  the  instructions  for 
implementing  the  control  and  security  structures  and  defmitions  of 
the  usage  indicators  and  applicable  codes. 

This  version  of  Part  10  of  the  Federal  Implementation  Guidelines, 
based  on  the  ANSI  ASC  XI 2  Version  003  Release  070  standards, 
supersedes  and  cancels  the  August  1994  version  of  Part  10. 

Except  where  specifically  otherwise  indicated,  this  document 
directs  how  the  agencies,  components  and  activities  of  the  United 
States  Federal  government  will  exchange  Electronic  Data 
Interchange  (EDI)  data  formatted  in  accordance  with  the  provisions 
of  the  ANSI  ASC  X12  standards. 


10.1  INTRODUCTION 
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The  power  of  the  American  National  Standards  Institute  (ANSI) 
Accredited  Standards  Committee  (ASC)  XI 2  standard  is  in  its 
building  block  concept,  which  standardizes  the  essential  elements 
of  business  transactions.  The  concept  is  analogous  to  a  "standard 
bill  of  materiel  and  the  construction  specifications,"  which  gives  the 
architect  flexibility  in  what  can  be  designed  with  standardized 
materiel  and  procedures.  The  Electronic  Data  Interchange  (EDI) 
system  designer,  like  the  architect,  uses  the  ASC  X12  standards  to 
build  business  transactions  that  are  often  different  because  of  their 
function  and  yet  utilize  the  ASC  X12  standards.  The  "bill  of 
materiel  and  the  construction  specification"  of  ASC  XI 2  are  the 
standards  found  in  the  published  technical  documentation. 

ASC  X12.3,  December  1996  — The  Data  Element  Dictionary 
specifies  the  data  elements  used  in  the  construction  of  the  segments 
that  comprise  the  transaction  sets  developed  by  ASC  XI 2. 

ASC  X12.5,  December  1996  — The  Interchange  Control  Structure 
provides  the  interchange  control  segment  (also  called  an  envelope), 
consisting  of  a  header  and  trailer,  for  the  EDI  transmission;  it  also 
provides  a  structure  to  acknowledge  the  receipt  and  processing  of 
the  envelope. 

ASC  XI  2.6,  December  1996  — The  Application  Control  Structure 
defines  the  basic  control  structures,  syntax  rules,  and  semantics  of 
EDI. 

ASC  XI 2.22,  December  1996  — The  Data  Segment  Directory 
provides  the  definitions  and  specifications  of  the  segments  used  in 
the  construction  of  transaction  sets  developed  by  ASC  XI 2. 
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ASC  X12.58,  December  1996  —  The  Security  Structures  define  the 
data  formats  for  authentication,  encryption,  and  assurances  in  order 
to  provide  integrity,  confidentiahty,  verification  and  non- 
repudiation  of  origin  for  two  levels  of  exchange  of  Electronic  Data 
Interchange  (EDI)  formatted  data:  ftinctional  group  and  transaction 
set  level. 

X12.59,  December  1996  —The  Implementation  of  EDI 
Structure/Semantic  Impact  provides  a  clear  distinction  between  the 
syntax  of  XI 2  structures  and  the  semantics  of  transaction  set  usage. 

X12C/TG 1/95-65  —  Technical  Report  Reference  Model  for  the 
Acknowledgment  and  Tracking  of  EDI  Interchanges  summarizes 
the  use  of  the  ANSI  ASC  XI 2  control  elements  and  standards  for 
the  acknowledgment  and  tracking  of  EDI  interchanges. 

International  Telecommunication  Union  -  Telecommunication 
Standardization  Sector  (ITU-T)  Recommendation  X.509  (J 993)/ 
ISO/IEC  9594-8  (1995),  Information  Technology-  Open  Systems 
Interconnection-  The  Directory  :  Authentication  Framework.  The 
Directory,  defines  a  framework  for  the  provision  of  authentication 
services  by  the  Directory  to  its  users.  It  specifies  the  form  of 
authentication  information  held  by  the  Directory,  describes  how 
authentication  information  may  be  obtained  from  the  Directory, 
states  the  assumptions  made  about  how  authentication  information 
is  formed  and  placed  in  the  Directory,  defmes  three  ways  in  which 
applications  may  use  authentication  information  to  perform 
authentication,  and  describes  how  other  security  services  may  be 
supported  by  authentication. 

In  addition  to  using  existing  standards  to  build  specific  transactions, 
the  standards  may  be  used  to  provide  control  and  tracking  of 
interchanges  if  accomplished  in  a  specific  standardized  approach. 
ANSI  ASC  XI 2  has  defmed  and  approved  several  control  structures 
and  Transaction  Sets  intended  to  augment  EDI  auditing  and  control 
systems.  It  is  the  intent  of  these  standards  to  provide  a  tracking 
mechanism  for  EDI  data  as  it  moves  through  the  transmission  cycle. 
Through  the  implementation  of  these  tracking  tools  and  analysis  of 
the  resulting  information,  delay  or  failures  in  delivery  can  be 
identified  and  corrected. 

The  work  accomplished  by  ANSI  ASC  XI 2C  in  this  area  produced 
a  generic  acknowledgment  model  that  has  been  adapted  to  support 
Federal  Government  EDI  processes.  Implementation  of  the 
acknowledgment  mechanisms  identified  by  this  model  will  provide 
a  basic  capability  to  track  interchanges  as  they  flow  from  senders 
through  Service  Request  Handlers  (SRH)  to  receivers  across  the 
EC/EDI  Infrastructure.  (An  SRH  is  a  service  provider  whose 
primary  function  is  to  provide  communications  services  between 
other  components  in  the  model.)  This  basic  capability  will  provide 
functionality  for  each  component  to  determine  translation  and 
transmission  status,  including  current  location  and  disposition  of  an 
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interchange.  Use  of  the  implemented  acknowledgment  mechanisms 
to  determine  singular  event  status  can  provide  components  with  the 
information  necessary  to  obtain  some  level  of  confidence  that 
interchanges  are  flowing  through  the  infrastructure  properly.  Taken 
as  a  sequence  of  acknowledgment  events,  the  model  provides 
senders  with  a  means  to  track  interchanges  from  generation  to 
delivery  to  a  Service  Request  Handler  at  the  boundary  of  the 
infrastructure,  without  imposing  the  processing  and 
communications  overhead  that  would  be  required  for  true 
application  to  application  acknowledgments. 

In  addition,  the  implemented  acknowledgment  mechanisms  of  this 
model  will  allow  individual  components  to  build  upon  or  enhance 
their  internal  audit  trail  processes. 

This  part  of  the  Federal  Implementation  Guidelines  is  meant  to  be 
an  overarching  architecture  of  the  control  and  security  structure 
which  the  government  is  implementing  in  the  Electronic  Commerce 
Infrastructure  (ECI)  and  other  government  EC  activities.  However, 
not  all  the  parts  of  the  architecture  will  be  implemented 
immediately.  The  specifics  of  which  parts  are  actually 
implemented  will  be  defined  in  agreements  between  actual 
components  in  the  trading  network  and  architecture,  such  as  Value 
Added  Networks  (VANs)  and  government  users  of  the  ECI. 

It  is  not  the  intent  of  this  guideline  to  specify  how  the  implemented 
acknowledgment  mechanisms  are  to  be  used.  While  support  of 
these  mechanisms  is  required,  their  usage  between  infrastructure 
components  will  be  as  agreed  between  those  components.  As  an 
example,  the  use  of  certain  acknowledgment  mechanisms  between 
the  government  and  VANs  is  specified  in  a  VAN  Licensing 
Agreement  (VLA).  Where  there  is  a  conflict  between  the 
implementation  guidance  provided  in  Part  10  and  the  VLA,  the 
VLA  shall  take  precedence.  Also,  the  use  of  acknowledgments 
between  Government  Points  of  Translation  (GPoT)  and  other 
infrastructure  components  can  be  as  mutually  agreed  upon. 

The  Service  Level  Agreement  (SLA)  between  the  ECI  and  the 
respective  government  Automated  Information  Systems  (AIS)  acts 
in  a  similar  manner  as  the  VLA.  Where  there  is  a  conflict  between 
the  implementation  guidance  provided  in  Part  10  and  the  SLA,  the 
SLA  shall  take  precedence. 

By  focusing  on  basic  acknowledgment  functionality  that  is 
independent  of  communications  protocols,  enhanced  tracking  of 
interchanges  is  accomplished  without  requiring  individual 
components  to  adhere  to  or  support  a  full  accountability  system. 

For  further  clarification  of  acronyms,  abbreviations,  and  codes, 
refer  to  ASC  X12  published  technical  documentation.  For  copies, 
contact  either  the  EDI  focal  point  within  your  service  or  agency,  or, 
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alternatively,  contact  the  administering  body  (see  Section  1.3  of 
these  guidelines). 
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10.2     CONTROL  SEGMENTS 

In  addition  to  communications  control,  the  EDI  interchange 
structure  provides  the  standards  user  with  multiple  levels  of  control 
to  ensure  data  integrity.  It  does  so  by  using  header  and  trailer 
control  segments  designed  to  identify  uniquely  the  start  and  end  of 
the  interchange  functional  groups  and  transaction  sets.  The 
relationship  of  these  control  segments  is  shown  in  Figure  10.2-1. 
Control  Segment  specifications  are  defined  in  Section  10.6. 


10.2.1  Description  of  Use 

The  interchange  header  and  trailer  segments  (ISA/IEA)  along  with 
the  optional  interchange  acknowledgment  segments  (TAl  and  TA3) 
constitute  the  interchange  control  structure  (i.e.,  an  interchange 
envelope).  Interchange  control  segments  perform  the  following 
functions: 


•  Define  data  element  separators,  subelement  separators  and  data 
segment  terminators 

•  Provide  control  information 

•  Identify  interchange  sender  and  receiver 

•  Allow  for  authorization  and  security  information. 

The  actual  interchange  control  structure  includes  neither  the  group 
control  structures  nor  the  transaction  control  structures;  these  are 
defined  by  ASC  XI 2  as  application  control  structures,  and  their 
version  and  release  may  differ  fi-om  those  for  the  interchange 
envelope.  An  interchange  envelope  encompasses  one  or  more 
functional  groups  (GS/GE),  which,  in  turn,  enclose  one  or  more 
related  transaction  sets  (ST/SE).  The  relationship  for  these 
structures  is  illustrated  in  Figure  10.2-1. 

The  purpose  for  GS/GE  functional  grouping  is  to  provide  an 
additional  control  envelope  surrounding  like  transaction  sets 
conforming  with  a  unique  Implementation  Convention  (IC).  Their 
usage  is  prescribed  as  interchange  control  segments  in  order  to 
present  a  consistent  methodology  for  electronic  data  interchange 
within  the  government  community  and  for  commercial  entities  that 
conduct  EDI  business  with  the  government. 

Implementation  Note:  The  Federal  Government  Electronic 
Commerce  Infrastructure  (ECI)  shall  send  and  receive  textual  data 
ASCII  encoded.  If  unencrypted  binary  segments  are  filtered.  Base 
64  filtering  shall  be  used. 
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Note: 


When  an  Interchange  contains  TA3s,  It  shall  contain  only  TA3s.  The  TA3s  replace 

all  Functional  Groups,  Security  Envelopes,  Transaction  Headers  and  Trailers,  as  well  as 

Detail  Segments  in  the  above  diagram. 


Figure  10.2-1.  Hierarchical  Structure. 
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10.2.1.1  Data  Element,  Data  Segment,  and  Component  Data 
Element  Separation 

In  ASC  XI 2  documentation,  the  data  element  separator  is 
graphically  displayed  as  an  asterisk  (*).  The  actual  data  element 
separator  employed  within  the  interchange  envelope  dictates  the 
value  for  the  entire  interchange.  The  first  occurrence  of  the  data 
element  separator  is  at  the  fourth  byte  of  the  interchange  control 
header.  The  value  appearing  there  dictates  the  data  element 
separator  used  through  the  next  interchange  trailer. 

In  a  similar  manner,  the  interchange  control  header  establishes  the 
value  to  be  used  for  segment  termination  within  an  interchange. 
ASC  XI 2  documentation  represents  this  graphically  by  a  new  line 
(N/L).  The  first  instance  of  segment  termination  occurs 
immediately  following  the  ISA  16  data  element,  and  the  data  value 
occurring  there  sets  the  value  for  the  interchange. 


Designation  of  a  component  data  element  separator  differs  fi'om  the 
other  separators  in  that  the  ISA  segment  provides  a  discrete  element 
(ISA16)  for  defining  the  component  data  element  separator  data 
value. 

Implementation  Note:: 

1.  ASCII  hexadecimal  character  IC  shall  be  used  as  the  segment 
terminator  in  Federal  Government  interchanges. 

2.  ASCII  hexadecimal  character  ID  shall  be  used  as  the  data 
element  separator  in  Federal  Government  interchanges. 

3.  ASCII  hexadecimal  character  IF  shall  be  used  as  the  component 
element  separator  in  Federal  Government  interchanges. 

4.  These  characters  are  reserved  for  these  purposes  and  shall  not 
be  used  in  data  elements,  except  that  they  may  be  used  in  data 
element  785,  Binary  Data. 

10.2.1.2  Identification  of  Implementation  Convention 

The  Federal  Government  develops  and  maintains  Implementation 
Conventions  (ICs)  based  on  ASC  XI 2  standards.  All  entities 
conducting  EDI  business  within  the  Government  or  externally  with 
the  Goverrmient  shall  com.ply  with  all  applicable  ICs.  ICs  are 
available  from  National  Institute  of  Standards  and  Technology 
acting  as  the  secretariat  for  the  Federal  EDI  Standards  Management 
Coordinating  Committee  (FESMCC).  Conventions  on  the  use  of 
interchange  control  structures  are  provided  herein  to  document  a 
consistent  approach  to  control  structure  content.  The  functional 
group  control  structures  include  the  ability  to  identify  specific  ICs 
to  which  the  Transaction  Sets  contained  within  that  group  conform. 
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Interchange  senders  will  provide  the  ASC  XI 2  Version/ 
Release/Subrelease  and  implementation  convention  identifier  in 
GS08.  This  identifier  uniquely  identifies  the  convention  to  which 
the  transaction  set  conforms. 

Implementation  Note:  Envelope  control  segments  have  few  options 
and,  except  for  minor  tailoring,  are  identical  for  every  EDI 
interchange.  The  tailoring  involves  the  code  values  selected  for  the 
GSOl  and  GS08  elements.  GSOl  classifies  the  particular 
transaction  set(s)  within  a  functional  group  and  GS08  identifies  the 
specific  IC  with  which  the  transactions  contained  within  the  group 
comply.  (Note:  The  version  and  release  identified  in  ISA  1 2  pertains 
to  the  interchange  control  envelope,  not  to  the  contained 
transaction  sets.) 

The  Version/Release/Industry  Identifier  Code  (GS08)  is  structured 
as  follows: 


Positions  1  through  6: 


Position  7 


Positions  8  through  1 0 


Position  1 1 : 


Position  12: 


ANSI  ASC  XI 2  Version  and  Release 
number  (e.g.  003010)  upon  which  the 
IC  is  based. 

Organizational  Scope 

F  =  Federal 

D  =  DOD 

G  =  Government  (transitional) 

Transaction  Set  Identifier  Code  (e.g., 
850). 

Derivative:  A  character  used  to 
differentiate  between  different 
functional  implementations  of  the 
same  transaction  set. 

If  the  convention  is  not  a  derivative, 
an  underscore  (_)  will  appear  in  this 
position. 

A  sequential  number  starting  with  0 
and  incremented  by  1  each  time  the 
convention  is  re-issued. 


An  example  of  the  Version/Release/  Industry  Identifier  Code  for 
XI 2  Version  003050,  Federal  Specific  IC,  revision  1,  Commercial 
Invoice  (810C)  is  003050F810C1. 

10.2.1.3  Control  Numbers 
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ASC  X12  standards  provide  for  syntax  control  on  three  levels: 
interchange,  group,  and  transaction.  Within  each  level,  control 
numbers  exhibit  a  positive  match  between  the  header  segment  and 
its  corresponding  trailer  (i.e.,  ISA/IEA,  GS/GE,  and  ST/SE). 
Assignment  of  these  control  numbers,  at  each  level,  is  as  follows: 

Implementation  Note:  ISA/IEA  Interchange  Control  Numbers 
(ISAI3/IEA02). 

1.  The  nine-digit  interchange  control  number  is  usually  assigned 
by  the  originator 's  translation  software.  Originating  organizations 
may  use  any  numbering  scheme  consistent  with  their  business 
practices. 

2.  The  scheme  must  provide  sufficient  uniqueness  to  identify  each 
interchange.  Unique  identification  is  defined  as  the  triplet: 
Interchange  Sender  ID,  (ISA05.  ISA06).  the  Interchange  Receiver 
ID,  (ISA07,  ISA08)  and  the  nine-digit  Interchange  Control  Number 
(ISAI3).  This  triplet  shall  be  unique  within  a  reasonably  extended 
time  frame. 

3.  If  there  is  no  TA3,  Interchange  Delivery  Notice,  after  2  hours, 
then  retransmit  with  the  same  interchange  control  number  (ISA  1 3). 

4.  If  an  interchange  is  rejected,  the  corrected  interchange  shall 
have  a  new  interchange  control  number  (ISA  1 3). 

Implementation  Note:  GS/GE  Data  Interchange  Control  Numbers 
(GS06/GE02). 

1.  This  is  a  one  to  nine^digit  number  usually  assigned  by  the 
originator 's  translation  software.  This  number  uniquely  identifies 
functional  groups  transmitted  between  sending  and  receiving 
application  pairs.  Originating  organizations  may  use  any 
numbering  scheme  consistent  with  their  business  practices. 

2.  The  scheme  must  provide  sufficient  uniqueness  to  identify  each 
functional  group.  The  Group  Control  Number  value  (GS06), 
together  with  the  Application  Sender's  Code  (GS02),  Application 
Receiver 's  Code  (GS03),  and  Functional  Identifier  Code  (GSOI), 
shall  be  unique  within  an  extended  time  frame  —  such  as  a  year. 

Implementation  Note:  ST/SE  Transaction  Set  Control  Numbers 
(ST02/SE02).  The  originator 's  translation  software  usually  assigns 
the  transaction  set  control  number.  Originating  organizations  may 
use  any  numbering  scheme  consistent  with  their  business  practices. 
The  scheme  must  provide  sufficient  uniqueness  to  identify  each 
transaction  set,  within  the  context  of  the  functional  group. 

The  control  numbers  within  corresponding  header  and  trailer 
segments  must  match.  This  provides  a  means  to  detect  loss  of  data. 
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10.3  ADDRESSING 

The  purpose  of  addressing  is  to  provide  an  unambiguous  reference 
to  a  transmission's  sender  and  intended  receiver.  The  addressing 
model  used  by  the  Federal  Government  for  ASC  XI 2  EDI 
transmissions  is  graphically  depicted  in  Figure  10.3-1.  In  this 
model,  there  is  addressing  for  two  types  of  transmissions.  The  first 
is  an  interchange.  It  consists  of  control  segments  and  application 
data.  The  second  type  is  application  data.  Application  data  flow 
from  the  sending  to  the  receiving  applications  and  is  transported 
within  an  interchange.  Since  interchanges  are  assembled  by  the 
sending  translation  point  and  disassembled  by  the  receiving 
translation  point,  the  flow  of  an  interchange  is  defined  to  be  from 
translation  point  to  translation  point.  Application  data  must  be 
provided  to  the  sending  translation  point  by  the  sending  application 
and  is  depicted  as  a  User  Defined  File  (UDF).  It  must  also  be 
provided  to  the  receiving  application  by  the  receiving  translation 
point  and  is  also  depicted  as  a  UDF. 

While  the  model  depicts  data  flow  from  the  government  to  a 
vendor,  it  is  equally  applicable  in  the  reverse  flow. 


 LlLIili  F I  :i 
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Figure  10.3-1  Addressing  Model 


10.3.1.  Interchanges 

Interchanges  flow  between  translation  locations.  The  Government 
Point  of  Translation  (GPoT)  can  be  implemented  as  part  of  the 
government  Application  Information  System  (AIS),  as  part  of  the 
Electronic  Commerce  Processing  Node  (ECPN),  or  as  a  stand-alone 
function.  Likewise,  the  Industry  Point  of  Translation  (IPoT)  on  the 
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vendor  side  can  be  in  the  Vendor  Application,  as  part  of  the  VAN's 
services,  or  as  a  stand-alone  function. 

The  GPoT  and  IPoT  are  addressed  by  the  Interchange  Sender  ID 
(ISA05  and  ISA06)  and  Interchange  Receiver  ID  (ISA07  and 
ISA08)  data  elements.  These,  combined  with  the  Interchange 
Control  Number  (ISA  13),  create  a  triplet  that  defines  a  globally 
unique  identifier  for  the  interchange.  The  ASC  X12  Interchange 
flows  between  these  translation  points. 

Implementation  Note: 

1.  When  an  interchange  contains  one-to-one  transactions,  the 
Interchange  Sender  ID  (ISA06)  and  Interchange  Receiver  ID 
(IS AOS)  data  elements  shall  be  the  addresses  of  the  interchange 
translation  points  (both  government  and  non-government). 

2.  Translation  Points  (ISA06  and  ISA08)  shall  be  identified  via  a 
unique  identifier  from  one  of  the  sources  listed  as  allowable  codes 
in  the  IS  AO  5  definition  in  section  10.6.  The  Data  Universal 
Numbering  System  (D-U-N-S)  number  and  D-U-N-S  +4  are  the 
preferred  identifiers. 

3.  All  commercial  and  government  entities  conducting  business 
electronically  shall  provide  their  translation  point  (ISA06/ISA08) 
codes  during  registration. 

4.  In  the  ECI,  when  an  interchange  contains  public  transactions 
the  IS  AOS  will  be  addressed  individually  to  all  certified  VANs,  not 
necessarily  each  IPoT.  The  ISA06  will  contain  the  ECPN's 
address. 

10.3.2  Application  Sender  and  Receiver  Codes 

Application  data  is  transported  within  the  mterchange  via  groups. 
Group  addressing  (GS02/GS03)  must  define  the  user  application 
end  points  shown  in  figure  10.3-1  as  the  AIS  and  the  Vendor 
Application.  These  addresses  are  locally  unique  and  are  defined 
between  the  translation  point  and  its  customers.  The  data  that  flows 
between  the  translation  points  and  the  Application  Senders  and 
Receivers  are  not  defined  by  ASC  XI 2,  but  are  in  a  format  agreed 
between  the  applications  and  their  translation  points. 

ASC  XI 2  standards  provide  for  the  identification  of  senders  and 
receivers  on  two  levels,  the  interchange  and  the  group.  The  group 
level  identifies  application  senders  and  receivers.  Depending  on 
where  translation  is  performed,  the  sender/receiver  IDs  may  be  the 
same  at  the  interchange  and  group  levels  and  may  use  any  number 
of  available  naming  schemes. 

At  the  GS/GE  level,  D-U-N-S  and  D-U-N-S  plus  4  are 
recommended,  especially  for  identifying  government  organizations. 
Other  identifiers  may  be  used. 
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A  D-U-N-S  number  may  be  acquired  from  Dun  and  Bradstreet  and 
the  plus  4  portion  of  the  number  is  assigned  and  maintained 
internally  by  each  entity.  Specific  use  of  these  numbers  is  provided 
for  in  the  control  structures  section  of  this  document. 

Implementation  Note: 

1.  The  GS02/03  identifiers  need  be  unique  only  within  the  context 
of  the  associated  ISA  address. 

2.  All  commercial  and  government  entities  conducting  business 
electronically  shall  provide  their  Application  Sender  and  Receiver 
(GS02/GS03)  codes  during  registration. 
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10.4  ACKNOWLEDGMENTS 

The  successful  conduct  of  business  via  EDI  requires  that  trading 
partners  be  able  to  determine  when  transactions  were  received,  not 
received,  received  in  error,  or  otherwise  did  not  complete  the 
transmission  or  receiver  application  processing  cycle.  The 
generation  or  handling  of  these  events  may  be  communications 
based,  EDI  processing  based,  or  both.  In  addition,  senders  may 
desire  to  know  such  information  on  an  exception  basis,  such  as 
reporting  only  for  error  conditions,  or  they  may  need  regular 
indication  of  the  status  of  delivery  to  allow  them  to  maintain  local, 
internal  audit  information.  Also,  providers  of  communications 
services  may  need  to  know  when  interchanges  for  which  they  have 
accepted  responsibility  were  forwarded  and  accepted  by  the  next 
service  provider  in  the  transmission  path,  or  whether  forwarding 
was  not  successful. 

In  either  scenario,  the  transmission  or  processing  of  interchanges 
can  be  viewed  as  an  acknowledgment  event  in  a  general  sense, 
creating  the  need  for  some  response.  From  a  sender's  perspective, 
the  acceptance  of  their  interchange  by  a  translator  or 
communications  provider  is  an  acknowledgment  event  that  could 
either  be  indicated  by  a  simple  receipt,  or  a  more  thorough 
reporting  of  what  actions  were  taken  after  receipt.  For  a  service 
provider,  forwarding  interchanges  can  also  result  in  an 
acknowledgment  event  being  created  that  calls  for  an 
acknowledgment  action  to  take  place. 

Taken  as  a  set  of  acknowledgment  requirements,  these  and  other 
events  can  be  considered  as  a  set  of  circumstances  which  results  in 
or  require  some  acknowledgment  action  to  take  place.  Rather  than 
consider  every  possible  action  and  event,  a  basic  sub-set  of  these 
events  can  be  defined  that  describes  the  majority  of  cases  that  form 
a  generalized  picture  of  tracking  interchanges.  Together  with 
acknowledgment  mechanisms  that  relate  to  those  events  and 
specific  components  that  create  or  respond  to  those  events,  an 
acknowledgment  model  can  be  described. 

ANSI  ASC  X12C  has  worked  in  this  area,  having  produced  a 
generic  Acknowledgments  Model  in  X12C/TG1/95-65  —  Technical 
Report  Reference  Model  for  the  Acknowledgment  and  Tracking  of 
EDI  Interchanges.  This  technical  report  identifies  specific  entities 
in  the  EDI  communications  and  processing  path  that  serve  as  the 
event  generators  or  handlers,  as  well  as  identifying  XI 2  standards 
based  acknowledgment  mechanisms.  Also,  the  senders  and 
receivers  of  the  interchanges  are  recognized  as  being  the 
terminating  application  systems  for  which  the  EDI  transactions  are 
sent  from  or  sent  to,  regardless  of  where  translation  occurs.  The 
government  has  taken  the  ANSI  XI 2  approach  to  an 
acknowledgments  model,  refining  it  through  identification  of 
specific  entities  and  acknowledgment  events.  Support  for  this 
model  will  provide  users  and  service  providers  with  the  ability  to 
track  interchanges  and  respond  to  requests  for  status  of  such 
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interchanges.  In  addition,  the  internal  audit  trail  processes  of  each 
entity  will  be  enhanced  with  the  availability  of  specified  event 
mapping. 

10.4.1  Description  of  Acknowledgment  IVIodel 

As  adapted  from  the  generic  model  developed  within  ASC  X12C, 
the  Government  Acknowledgment  Model  identifies  specific 
components,  acknowledgment  events,  and  XI 2  mechanisms  that 
are  related  to  those  events.  Based  upon  the  Electronic  Commerce 
Processing  Node  (ECPN)  as  a  central  component,  the  model 
establishes  a  view  of  the  EC/EDI  Infrastructure  as  encompassing 
commercial  and  government  entities,  as  well  as  service  providers 
and  users. 

In  this  model,  service  providers  are  those  components  that  provide 
translation  services,  communications  services,  or  some  EDI 
processing  services.  Specifically,  the  model  identifies  the  ECPNs, 
VANs  and  Translation  Points  as  service  providers.  A  Service 
Request  Handler  (SRH)  is  a  service  provider  whose  primary 
function  is  to  provide  communications  services  between  other 
components  in  the  model.  Users  include  Trading  Partners  (TPs) 
and  Automated  Information  Systems  (AISs). 

The  acknowledgment  mechanisms  identified  in  the  model  include 
unspecified  as  well  as  X12  based  mechanisms.  Where  the  model 
has  identified  an  acknowledgment  event  but  does  not  specify  a 
mechanism  for  handling  that  event,  it  is  implied  that  components 
involved  in  that  event  will  agree  on  what  mechanism  will  be  used. 

XI 2  based  acknowledgment  mechanisms  include  control  segment 
structures  in  addition  to  transaction  sets.  The  Interchange  Delivery 
Notice  (TA3)  segment,  Data  Status  Tracking  (242)  transaction  set 
and  the  Functional  Acknowledgment  (997)  transaction  set  all  have 
distinct  properties  and  functions.  However,  their  use  in  a  general 
sense  as  acknowledgment  mechanisms  allows  a  sequence  of 
communications  and  processing  events  to  be  tied  together  in  a 
logical  stream.  Each  acknowledgment  event  is  mapped  to  an  XI 2 
standards  based  mechanism  according  to  where  the  event  takes 
place,  what  type  of  event  occurred,  and  what  role  the  receiving  or 
generating  component  plays  in  the  data  flow  stream. 

The  TA3  can  provide  information  on  the  status  of  delivery  of  an 
interchange,  the  time  an  interchange  was  received,  or  the 
disposition  of  an  interchange,  and  is  used  to  report  such  information 
between  Service  Request  Handlers.  The  Data  Status  Tracking 
(242)  transaction  set,  in  addition  to  providing  the  ability  to 
represent  the  information  contained  in  the  TA3,  allows  transmission 
status  information  to  be  conveyed  from  service  request  handlers  to 
senders.  The  Functional  Acknowledgment  (997)  transaction  set 
indicates  the  status  of  translation  of  the  interchange  header  and 
trailer  information.  These  mechanisms  are  more  fully  described 
later  in  this  section. 
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The  model,  as  depicted  in  Figures  10.4-1,  10.4-2,  10.4-3,  and  10.4- 
4,  identifies  the  sets  of  events  that,  through  implementation  and  use 
of  the  specified  acknowledgment  mechanisms,  provides  for  the 
tracking  of  interchanges  across  the  infrastructure. 

Implementation  Note: 

1.  While  the  requirement  for  acknowledgments  from  Government 
Points  of  Translation  (GPoT)  to  supported  AISs  was  identified,  no 
single  mechanism  could  be  identified.  It  is  therefore  left  to 
agreement  between  them  as  described  in  the  Service  Level 
Agreement. 

2.  TA 1  is  not  supported  in  this  acknowledgment  model 
implementation. 

3.  The  government  translation  function  can  be  implemented  as  part 
of  the  government  Application  Information  System  (AIS),  as  part  of 
the  Electronic  Commerce  Processing  Node  (ECPN),  or  as  a  stand- 
alone function.  GPoT acknowledgment  responsibilities  reside  at 
the  location  performing  translation. 

4.  The  vendor  translation  function  can  be  implemented  as  part  of 
the  Vendor  Application,  Value  Added  Network  (VAN)  or  as  a 
stand-alone  function.  IPoT  acknowledgment  responsibilities  reside 
at  the  location  performing  translation. 
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VAN 


IPoT 


Vendor 
Application 


Acknowledgment  Flow 
Notes: 

a.  The  GPoT  translation  function  may  be  performed  by  the  ECPN,  AIS,  or  by  a  separate  entity. 

b.  For  the  purposes  of  the  model,  the  govt-to-govt  scenario  is  represented  by  replacing  the  VAN-Translation 
components  with  a  GPoT  component. 

c.  The  IPoT  may  be  operated  by  the  VAN,  the  Vendor,  or  a  third  party.  In  all  cases,  the  IPoT  is  the  ultimate 
recipient  of  the  interchange  for  the  purposes  of  acknowledgment  in  this  model. 

d.  997s  and  242s  can  be  mapped  at  the  GPoT  to  UDFs  &  forwarded  to  the  AIS  as  agreed  between  the  GPoT 
and  their  customer  base.  242s  will  not  be  acknowledged  by  997s. 

e.  UDF  is  User  Defined  File  (flat  file,  proprietary  file). 

f.  The  use  of  824s  are  not  precluded  by  this  model. 

g.  Support  for  the  model  acknowledgment  mechanisms  is  mandatory.  The  manner  of  their  usage  is  as  detailed 
further  in  the  Federal  EDI  Implementation  Guidelines  Part  10,  or  other  agreements. 


Figure  10.4-1  Acknowledgment  Model,  Commercial  to  Government 


Sequence  /  Event 

Mechanism 

From 

To 

1.  Receipt  of  UDF  by  GpoT 

TBD 

GPoT 

AIS 

2.  Translation  Result 

TBD 

GPoT 

AIS 

3.  Disposition  (Acknowledge  that  interchange 

TBD 

GPoT 

AIS 

has  left  GPoT) 

4.  Interchange  receipt  by  ECPN 

242 

ECPN 

GPoT 

5.  Interchange  Disposition  at  SRH 

TA3 

VAN 

ECPN 

(Government  to  Government) 

TA3 

GPoT 

ECPN 

5  a  Report  of  Interchange  Disposition  at  SRH 

242 

ECPN 

GPoT 

5b.  Report  of  Interchange  Disposition  at  SRH 

UDF 

GPoT 

AIS 

6.  Translation  Result 

997 

IPoT 

GPoT 

6a  Translation  Result 

UDF 

GPoT 

AIS 

Notes: 

a.  Not  all  events  1 ,  2  or  3  may  occur  or  need  to  be  acknowledged 

b.  TBD  indicates  the  acknowledgment  mechanism  is  to  be  determined,  or  as  agreed  to  between  components 

c.  UDF:  User  Defined  File  (flat  file,  proprietary  file  format) 

Figure  10.4-2  Acknowledged  Events,  Commercial  to  Government 
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TA3 


TA3 


N  otes; 

a.  Acknowledgments  among  VANs,  Translation  Points  and  their  customers  are  matters  to  be 
decided  by  them  and  are  not  defined  in  the  government  Acknowledgment  Model. 

b.  Some  GPoTs  may  generate  a  second  242,  with  the  ECPN  acting  as  a  pass-through. 

c.  For  government  to  government  scenario,  replace  the  VAN  with  a  GPoT.  The  ECPN  will 
generate  242s  in  lieu  of  TA3s  in  step  1  . 


Figure  10.4-3  Acknowledgment  Model,  Government  to  Commercial 


Sequence  /  Event 

Mechanism 

From 

To 

1 .  Interchange  receipt  by  ECPN 

TA3 

ECPN 

VAN 

(Government  to  Government) 

TA3 

ECPN 

GPoT 

2.  Interchange  Disposition  at  GpoT 

TA3 

GPoT 

ECPN 

2a.  Report  of  Interchange  Disposition  at  GPoT 

242 

ECPN 

VAN 

(Government  to  Government) 

242 

ECPN 

GPoT 

3.  Translation  Result 

997 

GPoT 

IPoT 

Note: 


In  step  2a,  the  disposition  report  carried  in  a  TA3  is  mapped  to  a  242 

Figure  10.4-4  Acknowledged  Events,  Government  to  Commercial 
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10.4.2  Interchange  Acknowledgment 

At  the  interchange  level,  acknowledgments  can  occur  for  a  number 
of  events.  Successful  translation,  syntax  error,  or  a  more  detailed 
acknowledgment  of  the  disposition  of  an  interchange  can  be 
reported.  The  available  XI 2  mechanisms  for  such  interchange 
acknowledgments  includes  the  Functional  Acknowledgment  (997) 
transaction  set,  the  Interchange  Acknowledgment  (TAl ),  and  the 
Interchange  Delivery  Notice  Segment  (TA3).  In  general,  the  997  is 
used  exclusively  for  reporting  the  status  of  syntactical  analysis  of 
the  interchange  by  the  receivmg  translator,  although  it  could  be 
used  as  an  indication  that  an  interchange  was  received.  The 
Interchange  Acknowledgment  (TAl)  is  not  supported  in  this 
acknowledgment  model.  The  Interchange  Delivery  Notice  (TA3) 
provides  the  ability  for  reporting  on  the  status  of  actions  taken  on  a 
particular  interchange.  The  manner  in  which  these  mechanisms  are 
used,  and  the  features  within  each  that  are  utilized,  provides  a  set  of 
tools  for  building  a  sequence  of  acknowledgments  for  the  life  cycle 
of  an  interchange  as  it  flows  across  an  infrastructure. 

10.4.2.1  TA3 

The  purpose  of  the  TA3  is  to  provide  a  notice  from  the  receiving 
SRH  to  the  sending  SRH  that  an  interchange  was  delivered,  not 
delivered,  refused,  purged,  or  transferred  to  the  next  SRH.  It 
provides  a  notification  of  action  taken,  notice  of  time/date  action 
was  taken,  and  the  ability  to  report  on  more  than  one  event. 

As  an  acknowledgment  mechanism  in  this  model,  the  TA3  is  used 
between  the  ECPN  and  VANs,  as  Service  Request  Handlers,  to 
indicate  the  status  of  interchanges  sent  from  the  government  to 
commercial  components,  as  well  as  the  reverse  scenario.  To 
indicate  outbound  delivery  status,  the  information  contained  in  this 
TA3  is  further  translated  into  a  242  transaction  set  and  sent  to 
GPoTs  for  their  use,  which  may  include  supplying  this  information 
to  the  interchange  sender.  The  government  uses  the  TA3  to  indicate 
interchange  delivery  status  to  the  sending  commercial  infrastructure 
components. 

Implementation  Note: 

1.  An  interchange  that  contains  a  TA3  shall  contain  only 

TA3s. 

2.  An  interchange  may  contain  multiple  TASs. 

3.  Upon  delivery  to  the  interchange  receiver's  mailbox,  a  TA3 
shall  be  generated. 

4.  If  deliveiy  to  the  interchange  receiver 's  mailbox  is  not 
made  within  2  hours,  a  TA3  shall  be  generated  indicating  a  non- 
deliveiy  status.  The  appropriate  reason  codes  will  be  specified.  A 
TA3  shall  be  generated  eveiy  2  hours  indicating  non-deliveiy  status 
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until  the  interchange  is  delivered  to  the  receiver 's  mailbox.  Upon 
delivery,  note  3  above  applies. 

5.  If  an  interchange  is  accepted  but  subsequently  determined 
to  be  non-deliverable,  a  TA3  shall  be  generated  indicating  code  RJ 
in  TA3J2  and  the  appropriate  reason  code  in  TA303. 

-  -  6.  No  acknowledgment  is  made  for  the  receipt  of  a  TA3. 

10.4.2.2  Data  Status  Tracking  (242)  Transaction  Set 

The  Data  Status  Tracking  (242)  transaction  set  conveys  status 
information  from  a  service  request  handler  to  the  interchange 
sender,  interchange  receiver,  or  both.  It  can  be  used  to  provide 
status  information  regarding  an  interchange  as  it  flows  from  an 
interchange  sender  through  one  or  more  service  request  handlers  to 
an  interchange  receiver  during  its  transmission  cycle. 

In  the  acknowledgment  model,  the  242  transaction  set  is  used  for 
two  events:  (1)  it  conveys  information  from  the  TA3  that  was 
generated  by  the  VAN  or  GPoT  that  received  the  interchange,  and 
(2)  it  is  used  to  provide  acknowledgment  information  between 
government  components.  Because  it  is  a  transaction  set,  translation 
sites  can  map  that  information  into  a  UDF  for  the  sending 
applications  use.  How  this  information  is  used  depends  on  the 
internal  business  processes  at  the  application  site,  and  is  not 
covered  by  the  model.  In  addition,  this  information  may  be  used  by 
the  GPoT  in  its  capacity  as  a  Service  Request  Handler  for  internal 
audit  trail  purposes. 

Implementation  Note: 

1.  For  interchanges  between  government  components,  a  242  shall 
be  generated  upon  delivery  to  the  interchange  receiver 's  mailbox. 
If  delivery  to  the  interchange  receiver 's  mailbox  is  not  made  within 
2  hours,  a  242  shall  be  generated  indicating  a  non-delivery  status. 

2.  The  242  transaction  set  shall  not  be  acknowledged  (via  a  997), 
nor  shall  it  be  used  to  report  the  final  disposition  of  a  997 
transaction  set . 

3.  Additional  242  acknowledgments  from  interconnect  service 
providers  may  be  required  by  additional  agreements  among  trading 
partners. 

10.4.2.3  Interchange  Acknowledgment  Segment  (TA1) 

The  Interchange  Acknowledgment  Segment  (TAl)  is  used  to 
acknowledge  receipt  of  one  interchange  header  and  trailer 
envelope. 

Implementation  Note:  The  TAI  is  not  supported  in  this 
acknowledgment  model. 
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10.4.3  Application  Advice  (824)  Transaction  Set 

Although  it  can  provide  acknowledgment  functionality,  use  of  the 
Application  Advice  (824)  transaction  set  is  not  specified  by  this 
model.  Currently,  it  is  primarily  used  on  an  exception  basis  for 
reporting  between  applications,  and  its  full  use  as  an 
acknowledgment  mechanism  within  the  model  would  create 
substantial  impact  on  the  communications  and  processing  systems. 

10.4.4  Functional  Acknowledgments  (997) 
Transaction  Set 

While  the  Functional  Acknowledgment  (997)  transaction  set  is  not 
part  of  the  interchange  control  structure,  it  is  integral  to  the  overall 
process  for  interchange  integrity,  and  for  completeness  of  the 
acknowledgment  model. 

Support  for  the  Functional  Acknowledgment  is  required  in  all 
cases.  The  997  verifies  (or  challenges)  the  syntactical  correctness 
(e.g.,  ability  to  translate)  of  transaction-level  data  within  a 
functional  group. 

Implementation  Note: 

1)  Syntactic  correctness  shall  be  determined  by  comparison  to  the 
requirements  of  the  applicable  implementation  convention,  not 
simply  the  ASC  XI 2  standard. 

2)  The  997  transaction  set  shall  not  be  acknowledged. 

3)  When  an  X12  transaction  containing  "Not  Used"  segments 
and/or  data  elements  is  received  by  the  Government,  the 
transaction  will  be  rejected  and  a  997  will  be  generated  indicating 
why  the  transaction  was  rejected. 
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10.5  SECURITY 

ASC  X12.58,  published  in  December,  1996,  provides  for  the 
implementation  of  security  services  at  the  functional  group  and 
transaction  set  levels.  The  available  security  services  include:  data 
integrity,  confidentiality,  assurance,  verification,  and  non- 
repudiation  of  origin.  These  services  may  be  implemented 
individually  or  in  any  combination. 

ASC  X12.58  can  meet  several  security  objectives.  Among  these 
are: 


•  The  recipient  of  an  EDI  transaction  can  verify  the  identity  of 
the  originator  of  the  transaction. 

•  The  recipient  of  an  EDI  transaction  can  verify  the  integrity  of 
its  contents. 


•     The  originator  of  an  EDI  transaction  can  provide 
confidentiality  for  its  contents. 

ASC  XI 2. 5 8  provides  a  mechanism  that  can  be  applied  to  the  XI 2 
functional  group  or  transaction  set,  in  contrast  to  other  alternatives 
which  are  usually  applied  to  the  entire  interchange.  ANSI  XI 2. 5 8 
is  transaction  data  independent.  When  XI 2. 5 8  security 
mechanisms  are  applied  inside  the  interchange,  they  can  be  handled 
and  routed  as  standard  XI 2  transactions  without  disrupting  the  end- 
to-end  security.  Since  security  services  are  applied  within  the 
interchange,  they  are  independent  of  the  mechanism  used  to 
transport  them.  Thus  X12.58  can  provide  security  even  when  the 
interchanges  leave  the  boundaries  of  the  ECI. 

The  Federal  Government  is  committed  to  providing  security 
services  for  ASC  XI 2  compliant  EDI  via  the  constructs  provided  by 
ASC  X12.58.  However,  very  significant  changes  to  those 
constructs  have  been  made  within  various  version/releases  of  the 
ASC  X12  standards.  Also,  ASC  X12.58  security  constructs  are  not 
backward  compatible.  That  is,  003070  constructs  may  not  be 
applied  to  provide  security  services  to  the  bulk  of  the  current 
federal  implementations,  which  are  in  version/release  3060, 
003050,  3040  and  earlier. 


10.5.1  Authentication 

•     Message  authentication  is  a  procedure  to  verify  that  received 
messages  have  not  been  altered.  A  hash  function,  a  public 
function  that  maps  a  message  of  any  length  into  a  fixed  hash 
value,  can  be  used  as  an  authenticator  when  used  in 
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conjunction  with  some  form  of  data  encryption,  such  as  digital 
signature. 

Implementation  Note:  Assurance  via  the  S2A/SVA  segments  shall 
be  used  in  lieu  of  authentication. 

10.5.2  Confidentiality  (Encryption) 

The  XI 2. 5 8  standards  allows  for  the  implementation  of  various 
algorithms  to  encrypt  X12  transactions.  Cryptographic  algorithms 
fall  into  two  categories:  secret  key  and  public-key.  Secret  key 
algorithms  are  based  on  both  the  sender  and  receiver  sharing  the 
same  secret  key  (i.e.,  key  unknown  to  other  parties).  This  key  is 
used  to  encrypt  the  transaction  prior  to  transmission  and  decrypt  it 
upon  receipt.  Public-key  algorithms  are  based  on  both  sender  and 
receiver  having  a  pair  of  keys,  one  public  and  one  private.  All 
exchanges  of  keys  between  sender  and  receiver  are  limited  to  the 
public  portion  only,  so  the  private  key  portion  is  protected. 
Initially,  the  Government  will  support  the  following  encryption 
algorithms: 

•  Data  Encryption  Standard  (DES) 

•  Triple  DES  (DE3) 

•  Rivest-Shamir-Adleman  (RSA) 

•  SKIPJACK 
Implementation  Note: 

1.  Confidentiality  services  may  be  applied  at  either  the  functional 
group  (GS/GE)  level,  the  transaction  set  (ST/SE)  level  or  both. 

2.  When  applied,  the  SIS  shall  be  inserted  immediately  after  the 
GS  segment  and  the  SJE  shall  be  inserted  immediately  prior  to  the 
GE  segment 

3.  When  applied,  the  S2S  shall  be  inserted  immediately  after  the  ST 
segment  and  the  S2E  shall  be  inserted  immediately  prior  to  the  SE 
segment. 

10.5.3  Assurance  (Digital  Signatures) 

A  digital  signature  is  an  authentication  technique  that  also  includes 
measures  to  counter  repudiation  by  the  source.  Assurances  (SI A  or 
S2A  and  SVA),  as  defined  in  X12.58,  allow  the  originator  of  the 
transaction  to  express  "business  intent"  via  a  digital  signature.  The 
Government  will  support  implementation  of  the  Digital  Signature 
Standard.  When  used,  one  S2A  and  one  SVA  are  inserted 
immediately  before  the  SE  segment  of  the  transaction  set  being 
assured.  If  subsequent  assurances  are  applied,  additional  S2A/SVA 
pairs  are  inserted  between  the  previous  assurance,  and  the  SE 
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segment  of  the  transaction  set  being  assured.  Detailed  instructions 
for  the  use  of  the  S2A  and  SVA  segments  are  contained  in  section 
10.6 

Implementation  Note: 

1.  Assurance  (digital  signature)  may  be  applied  at  either  the 
functional  group  (GS/GE)  level,  the  transaction  set  (ST/SE)  level  or 
both. 

2.  When  digital  signature  is  applied  at  the  group  level,  the  SI  A  and 
SVA  segment  pair(s)  shall  be  inserted  immediately  preceding  the 
GE  segment  of  the  group  being  assured  (digitally  signed). 

3.  When  digital  signature  is  applied  at  the  transaction  set  level,  the 
SI  A  and  SVA  segment  pair(s)  shall  be  inserted  immediately 
preceding  the  SE  segment  of  the  transaction  set  being  assured 
(digitally  signed). 

4.  When  both  assurance  and  confidentiality  are  applied,  assurance 
(SI  A  or  S2A  and  SVA)  shall  be  applied  first  and  then  confidentiality 
(SIS  and  SIE  or  S2S  and  S2E). 


10.5.4X12.58  Capabilities  by  Release 


ANSI  X12 
Release 

Authentication 

ncryption    jAssurance  j 

3040 

(Note  1) 

(Note  3) 

3050 

(Note  1) 

(Note  3) 

3060 

(Note  2) 

X 

X 

3070 

(Note  2) 

(Note  3) 

X 

NOTES: 

1 .  Authentication  accomplished  using  a  message  authentication  code 
(MAC).  The  MAC  is  a  hash  of  the  data. 

2.  Authentication  accomplished  as  a  by-product  of  the  digital  signature  or 
by  using  the  MAC  defined  in  earlier  releases  of  the  ANSI  XI 2  standard. 

3.  Private  (symmetric)  keys  supported  by  this  release.  Asymmetric  keying 
is  possible  but  not  without  some  "non-standard"  use  of  data  elements. 

10.5.5  Sequencing  of  Cryptographic  Techniques 

In  practical  situations,  the  users  of  the  X12.58  standards  will  choose 
combinations  of  features  rather  than  just  a  single  feature.  This  is  possible 
since  all  features  are  designed  to  be  used  in  isolation  or  in  any 
combination. 

Authentication  does  not  protect  the  confidentiality  of  the  message  because 
the  information  is  interchanged  in  its  plain  text  form.  Message  encryption 
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can  be  used  to  provide  confidentiality  while  using  authentication  to 
provide  integrity  protection  of  the  same  data.  When  both  authentication 
and  encryption  are  used,  the  authentication  is  performed  before  encryption 
of  the  original  plain  text  data. 

Where  more  than  one  service  is  selected  at  a  specific  level,  the  order  of 
processing  is: 

a.  Before  applying  any  security  services,  the  data  must  first  be  translated 
into  an  EDI  format 

b.  Addition  of  one  or  more  assurances 

c.  Authentication 

d.  Compression 

e.  Encryption 

f.  Filtering  for  data  communications 

When  assurance  segments  are  used,  they  must  be  added  to  unsecured  (not 
authenticated  or  encrypted)  transactions.  If  a  transaction  set  is  received 
(with  or  without  assurances)  with  encryption  and/or  authentication  applied 
by  the  originator,  the  transaction  set  must  be  either  decrypted  or 
authenticated  prior  to  the  addition  of  any  further  assurances.  Once  any 
assurances  have  been  added,  the  transaction  set  can  be  encrypted  or 
authenticated  prior  to  being  forwarded  to  additional  parties. 

When  applying  security  sei"vices  at  the  functional  group  level,  all  security 
services  at  the  transaction  set  level  must  be  completed  before  applying 
security  services  at  the  functional  group  level. 

The  receiving  organization  processes  the  received  message  in  the  reverse 
order,  starting  with  inverse  filtering,  followed  by  decryption,  and  then  by 
decompression,  validation  of  authentication  and  validation  of  the 
assurances.  When  processing  inbound  security  services  at  the  transaction 
set  level,  all  security  services  at  the  functional  group  level  must  be 
removed  before  processing  inbound  security  services  at  the  transaction  set 
level.  In  this  manner  the  receiving  organization  unwraps  the  EDI 
message  by  processing  the  security  services  and  removing  the  security 
segment  pairs  from  the  message  before  processing  the  next  security 
service. 


10.5.6  Transmission  of  Security  Segments 

Security  services  (authentication,  encryption  and  assurances)  are  provided 
at  two  levels  within  ASC  XI 2  in  conjunction  with  the  following 
envelopes: 

•  Functional  Group  (GS/GE  envelope) 

•  Transaction  Set  (ST/SE  envelope) 

At  each  of  these  levels,  authentication,  encryption  and  assurances  are  each 
optional.  Assurances  are  independent  of  authentication  or  encryption.  In 
addition,  any  service  used  at  one  level  is  independent  of  a  service  used  at 
the  other  level. 
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It  encryption  and/or  authentication  is  provided,  the  secunty  header 

segment  (SIS  or  S2S)  immediately  follows  the  segment  initiating  the 

beginning  of  this  level  (GS  or  ST);  the  security  trailer  segment  (SIE  or 

S2E)  precedes  the  segment  terminating  the  level  (GE  or  SE).  If  assurances 

are  present,  the  SI  A  or  S2A  segments  and  its  trailing  SVA  segment 

immediately  precedes  the  SE  or  GE  if  authentication  and/or  encryption  is 

not  used  and  immediately  proceed  the  SIE  or  S2E  segment  if 

authentication  and/or  encryption  is  used.  If  encryption  and/or 

authentication  at  both  levels  is  provided  and  if  assurances  are  used  at 

both  levels,  the  sequence  of  segments,  illustrating  these  levels,  is: 

TO  A     T     J.—    —l- _              TT     —  J 

ISA-Interchange  Header 

(Other  Groups  whether  secured  or  not  at  Level  1) 

GS-Functional  Group  Header 

S 1  S-Security  Header  Level  1 

(Other  Transaction  Sets  whether  secured  or  not  at  Level  2) 

SI-  Transaction  Set  Header 

ozb-oecunty  Header  Level  z 

(The  Transaction  Set  Segments) 

A         O               '  J—       A                               T              1  ^ 

S2A  -  Secunty  Assurance  Level  2 

bVA  -  Assurance  loken  Level  2 

(Other  optional  bZA-b\A  pairs  at  Level  z 

S2E-Security  Irailer  Level  2 

SE-Transaction  Set  Trailer 

(Other  Transaction  Sets  whether  secured  or  not  at  Level  2) 

SI  A  -  Assurance  Segment  Level  1 

SVA  -  Assurance  Token  Level  1 

(Other  optional  SIA-SVA  pairs  at  Level  1) 

S  IE-Security  Trailer  Level  1 

GE-Functional  Group  Trailer 

(Other  Functional  Groups  whether  secured  or  not  at  Level  1 ) 

lEA-Interchange  Trailer 
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10.6  Interchange  Control,  Acknowledgment  and 

Security  Segment  Specifications 

This  section  contains  the  implementation  conventions  for  the: 

•     Interchange  Control  Header  (ISA),  Version/release  003070 

•     Interchange  Delivery  Notice  Segment  (TA3) 

•     Functional  Group  Header  (GS),  Version/release  002003 

•     Functional  Group  Header  (GS),  Version/release  003010 

•     Functional  Group  Header  (GS),  Version/releases  003040 

tnrougn  UUiU/U 

•     Security  Header  Level  1  (SIS),  Version/releases  003040  and 

•     Security  Header  Level  1  (SIS),  Version/releases  003060  and 

Am  find 
UUiU/U 

•     Security  Header  Level  2  (S2S),  Version/releases  003040  and 

•     Security  Header  Level  2  (S2S),  Version/releases  003060  and 

AAT  ATA 

OUiO/0 

•     Security  Assurance  Level  2  (S2A),  Version/releases  003060 

and  003070 

•     Assurance  Token  Level  2  (S2A),  Version/releases  003060  and 

AATATA 
0030/0 

•     Security  Trailer  Level  2  (S2E),  Version/releases  003060  and 

003070 

•     Assurance  Segment  Level  1  (SIA),  Version/releases  003060 

and  003070 

•     Assurance  Token  Level  1  (SVA),  Version/releases  003060 

and  003070 

•     Security  Trailer  Level  1  (SIE),  Version/releases  003060  and 

•     Functional  Group  Trailer  (GE), 

•     Interchange  Control  Trailer  (lEA),  Version/release  003070 
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ISA  Interchange  Control  Header 

Mandatory 
1 

To  start  and  identify  an  interchange  of  zero  or  more  functional  groups  and  interchange- 
related  control  segments 


Segment: 

Usage: 
Max  Use: 
Purpose: 

Syntax  Notes: 
Semantic  Notes: 
Comments: 
Notes: 


L  Use  ASCII  Hexadecimal  ID  in  the  fourth  byte  of  the  Interchange  Control  Header. 
This  first  occurrence  of  an  element  separator  dictates  the  value  the  translation 
software  will  employ  throughout  the  interchange. 

2.  Use  ASCU  Hexadecimal  IC  after  ISA16.  This  first  occurrence  of  a  segment 
terminator  dictates  the  value  the  translation  software  employs  throughout  the 
interchange. 

3.  See  ISA16for  subelement  separator  usage. 


Must  Use 


Ref. 
Pes. 
ISAOl 


Must  Use  ISA02 


Data 
Element 
101 


102 


Data  Element  Summary 

Name  Attributes 
Authorization  Information  Qualifier  M    ID  2/2 

Code  to  identify  the  type  of  information  in  the  Authorization  Information 
GO  No  Authorization  Information  Present  (No  Meaningful 

Information  in  102) 

05  Department  of  Defense  (DoD)  Communication 
Identifier 

Use  to  indicate  the  Department  of  Defense  (DOD)  as 
the  information  authorizer.  Use  this  code  even  if  the 
sender  is  not  a  DOD  entity. 

06  United  States  Federal  Government  Communication 
Identifier 

Use  to  indicate  the  Federal  Government  as  the 
information  authorizer.  Use  this  code  even  if  the 
sender  is  not  a  Federal  Government  entity. 
Authorization  Information  M    AN  10/10 

Information  used  for  additional  identification  or  authorization  of  the 
interchange  sender  or  the  data  in  the  interchange;  the  type  of  information  is  set 
by  the  Authorization  Information  Qualifier  (101) 

1.  Use  to  provide  additional  identification  or  authorization  for  the  data  in  the 
interchange.  Otherwise,  fill  this  field  with  blank  characters. 

2.  When  used,  it  is  recommended  that  the  specific  coding  be  exchanged 
between  trading  partner  data  security  officials  to  ensure  preservation  of  data 
security. 
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Must  Use  ISA03 


Must  Use  ISA04 


Must  Use  ISA05 


Must  Use  ISA06 


103  Security  Information  Qualifier  M    ID  2/2 

Code  to  identify  the  type  of  information  in  the  Security  Information 

00  No  Security  Information  Present  (No  Meaningful 
Information  in  104) 

01  Password 

Use  based  on  trading  partner  agreement, 

104  Security  Information  M    AN  10/10 

This  is  used  for  identifying  the  security  information  about  the  interchange 
sender  or  the  data  in  the  interchange;  the  type  of  information  is  set  by  the 
Security  Information  Qualifier  (103) 

If  IS  AOS  is  code  00,  fill  this  field  mth  blank  characters.  Otherwise,  enter  a 
password  as  agreed  between  Trading  Partners. 

105  Interciiange  ID  Qualifier  -  - -^-^  -^  ^ 

Qualifier  to  designate  the  system/method  of  code  structure  used  to  designate 
the  sender  or  receiver  ID  element  being  qualified 
P-U-N-S  (Code  01)  or  D-U-N-S+4  (Code  16)  are prefered. 

01  Duns  (Dun  &  Bradstreet) 

02  SCAC  (Standard  Carrier  Alpha  Code) 

04  lATA  (International  Air  Transport  Association) 

08  UCC  EDI  Communications  ID  (Comm  ID) 

09  X.121  (CCITT) 

10  Department  of  Defense  (DoD)  Activity  Address  Code 
1 6  Duns  Number  With  4-Character  Suffix 

106  Interchange  Sender  ID  M    AN  15/15 

Identification  code  published  by  the  sender  for  other  parties  to  use  as  the 
receiver  ID  to  route  data  to  them;  the  sender  always  codes  this  value  in  the 
sender  ID  element 

7.  Enter  the  identifier  of  the  sender's  translation  point. 


Must  Use  ISA07 


Must  Use  ISA08 


2.  Left  justify  and  pad  on  the  right  with  blanks. 
105       Interchange  ID  Qualifier  M    ID  2/2 

Qualifier  to  designate  the  system/method  of  code  structure  used  to  designate 
the  sender  or  receiver  ID  element  being  qualified 
D-U-N-S  (Code  01)  or  D-U-N-S+4  (Code  16)  are  prefered 

01  Duns  (Dun  &  Bradstreet) 

02  SCAC  (Standard  Carrier  Alpha  Code) 

04  lATA  (International  Air  Transport  Association) 

08  UCC  EDI  Communications  ID  (Comm  ID) 

09  X.121  (CCITT) 

10  Department  of  Defense  (DoD)  Activity  Address  Code 
1 6  Duns  Number  With  4-Character  Suffix 

107       Interchange  Receiver  ID  M    AN  15/15 

Identification  code  published  by  the  receiver  of  the  data;  When  sending,  it  is 
used  by  the  sender  as  their  sending  ID,  thus  other  parties  sending  to  them  will 
use  this  as  a  receiving  ID  to  route  data  to  them 

ii.  Enter  the  identifier  of  the  receiver's  translation  point  (both  government 
'find  non-government). 
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Must  Use  ISA09 


2.  Left  justify  and  pad  on  the  right  with  blanks. 
108       Interchange  Date  M    DT  6/6 

Date  of  the  interchange 

1.  Express  the  UTC  (previously  known  as  GMT)  date  that  this  interchange 
was  created. 


Must  Use  ISAIO 


2.  Express  the  date  in  a  six-position  (YYMMDD)  format. 
109       Interchange  Time  M    TM  4/4 

Time  of  the  interchange 

/.  Express  the  UTC  (previously  known  as  GMT)  time  that  this  interchange 
was  created. 


Must  Use  ISAll 


Must  Use  ISA12 


Must  Use  ISA13 


Must  Use  ISA14 


Must  Use  ISA15 


2.  Express  the  time  in  a  four-position  (HHMM)  format. 

110  Interchange  Control  Standards  Identifier  M    ID  1/1 

Code  to  identify  the  agency  responsible  for  the  control  standard  used  by  the 
message  that  is  enclosed  by  the  interchange  header  and  trailer 

U  U.S.  EDI  Community  of  ASC  XI 2,  TDCC,  and  UCS 

111  Interchange  Control  Version  Number  M    ID  5/5 
This  version  number  covers  the  interchange  control  segments 

Use  to  identify  the  ASC  X12  version  and  release  for  the  interchange 
envelope,  not  the  transactions  carried  within  the  envelope. 

00307  Draft  Standards  for  Trial  Use  Approved  for  Publication 

by  ASC  X12  Procedures  Review  Board  through 
October  1996 

112  Interchange  Control  Number  M    NO  9/9 

A  control  number  assigned  by  the  interchange  sender 
Originating  activities  may  use  any  numbering  scheme  consistent  with  their 
business  practices.  However,  the  scheme  must  uniquely  identify  each 
interchange  over  a  very  long  period  of  time. 

113  Acknowledgment  Requested  M    ID  1/1 
Code  sent  by  the  sender  to  request  an  interchange  acknowledgment  (TAl) 
This  request  for  acknowledgment  applies  only  to  return  of  a  TAl, 
Interchange  Acknowledgment  It  does  not  apply  to  other  acknowledgments 
(e.g.  TA3  or  transaction  set  242)  as  required  by  Part  10  of  the  Federal 
Guidelines.  Since  the  TAl  is  not  supported,  no  acknowledgment  shall  be 
requested. 

0  No  Acknowledgment  Requested 

Use  this  code  to  indicate  an  interchange 
acknowledgment  via  TAl  shall  not  be  returned  by  the 
interchange  receiver. 

114  Test  Indicator  M    ID  1/1 
Code  to  indicate  whether  data  enclosed  by  this  interchange  envelope  is  test  or 
production 

P         -         Production  Data 

Use  to  identify  all  data  other  than  test  data. 
T  Test  Data 

Use  when  testing  interchanges. 
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Must  Use    ISA16  115      Component  Element  Separator  M    AN  1/1 

Type  is  not  applicable;  the  component  element  separator  is  a  delimiter  and  not 
a  data  element;  this  field  provides  the  delimiter  used  to  separate  component 
data  elements  within  a  composite  data  structure;  this  value  must  be  different 
than  the  data  element  separator  and  the  segment  terminator 
Enter  ASCII  Hexadecimal  IF.  The  value  of  this  element  dictates  the  value 
the  translation  software  employs  for  component  element  separation 
throughout  the  interchange. 
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Segment: 

Usage: 
Max  Use: 
Purpose: 


Syntax  Notes: 


Semantic  Notes: 


Comments: 
Notes: 


TA3  Interchange  Delivery  Notice  Segment 

Mandatory 
1 

To  provide  a  notice  from  the  receiving  service  request  handler  to  the  sending  service 
request  handler  that  an  interchange  was  delivered  or  not  delivered  to  the  interchange 
receiver's  mailbox,  or  some  other  ancillary  service  was  performed,  and  that  the 
interchange  receiver  retrieved,  refused,  or  purged  the  interchange;  TA3  is  exchanged 
only  between  service  request  handlers;  use  of  the  TA3  segment  is  optional 

1  If  either  TA322  or  TA323  is  present,  then  the  other  is  required. 

2  If  either  TA324  or  TA325  is  present,  then  the  other  is  required. 

3  If  either  TA326  or  TA327  is  present,  then  the  other  is  required. 

1  TA301  and  TA302  identify  the  service  request  handlers  processing  the  interchange 
being  reported. 

2  TA304  through  TA3 1 1  and  TA3 1 8  through  TA32 1  are  used  to  identify  the 
interchange  whose  status  is  being  reported. 

3  TA312  through  TA314  identify  the  action  being  reported  and  the  date  and  time  that 
action  was  performed.  TA315  through  TA317  provide  a  second  set  of  interchange 
action  code,  date  and  time  that  can  be  included  if  a  given  TA3  is  reporting  on  more 
than  one  event. 

4  TA322  through  TA327  contain  optional  information  exchanged  by  service  request 
handlers  to  supply  additional  information  concerning  actions  taken  upon  the 
interchange  being  reported. 


1.  Only  one  interchange  action  may  be  reported  per  TA3.  If  multiple  events  are  to  be 
reported,  multiple  TA3s  must  be  used. 

2.  Only  one  interchange  control  structure  error  may  be  reported  per  TA3.  If  multiple 
errors  are  to  be  reported,  multiple  TA3s  must  be  used. 


Ref. 
Pes. 

Must  Use  TA301 


Must  Use  TA302 


Must  Use  TA303 


Data 
Element 
138 


139 


143 


Data  Element  Summary 

Name  Attributes 
Service  Request  Handler  ID  Qualifier  M    ID  2/2 

This  is  a  code  identifying  the  service  request  handler 

Cite  the  code  FG  to  indicate  the  Federal  Government  Do  so  whether  the 

originator  is  a  public  or  private  organization. 

Service  Request  Handler  ID  M    AN  1/15 

This  is  the  identification  code  of  the  sending  service  request  handler 

Cite  the  D-U-N-S  or  D-U-N-S+4  of  the  service  request  handler  providing  this 

notice  of  interchange  delivery. 

Error  Reason  Code  M    ID  3/3 

The  code  indicates  the  error  found  or  not  found  in  processing  the  control 
structure  or  in  delivery 

000  No  Errors 

001  The  Interchange  Control  Number  in  the  Header  and 
Trailer  Do  not  Match;  the  Value  from  the  Header  is 
used  in  the  Acknowledgment 

002  This  Standard  as  Noted  in  the  Control  Standards 
Identifier  is  not  Supported 
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Must  Use  TA304 


Must  Use  TA305 


144 


145 


Must  Use  TA306 


Must  Use  TA307 


Must  Use  TA308 


146 


147 


148 


003  This  Version  of  the  Controls  is  not  Supported 

004  The  Segment  Terminator  is  Invahd 

005  Invalid  Value  as  Shown  in  the  Reported  Interchange 
Control  Number 

006  Invalid  Value  as  Shown  in  the  Reported  Interchange 
Date 

007  Invalid  Value  as  Shovra  in  the  Reported  Interchange 
Time 

008  Invalid  Value  as  Shown  in  the  Reported  Interchange 
Sender  ID  Qualifier 

009  Invalid  Value  as  Shown  in  the  Reported  Interchange 
Sender  ID 

010  Invalid  Value  as  Shown  in  the  Reported  Interchange 
Receiver  ID  Qualifier 

011  Invalid  Value  as  Shown  in  the  Reported  Interchange 
Receiver  ID 

0 1 6  Trading  Partnership  not  Established 

0 1 7  Invalid  Number  of  Included  Groups  Value 

018  Invalid  Control  Structure 

019  Improper  (Premature)  End-of-file  (Transmission) 

020  Duplicate  Interchange  Control  Number 

02 1  Invalid  Data  Element  Separator 

022  Invalid  Component  Element  Separator 

023  Failure  to  Transfer  Interchange  to  the  next  Service 
Request  Handler 

03 1  Receiver  Not  On-line 

032  Abnormal  Conditions 

Reported  Start  Segment  ID  M    AN  2/3 

This  contains  the  start  segment  ID  of  the  original  interchange,  functional  group 
or  transaction  set 

For  ANSI  ASC  XI 2  interchanges,  the  start  segment  ID  is  always  ISA. 
Reported  Controi  Number  M    AN  1/14 

This  is  the  control  number  value  of  the  original  interchange,  functional  group 
or  transaction  set 

Cite  the  control  number  assigned  in  the  original  interchange  control  header 
(appearing  in  ISA13)  for  which  notice  is  being  provided.  With  this  control 
number,  the  TA3  is  linked  to  the  original  interchange  envelope. 
Reported  Date  M    AN  1/8 

This  is  the  date  value  of  original  interchange  or  ftmctional  group 

Cite  the  date  appearing  in  ISA09  of  the  interchange  for  which  delivery  notice 

is  being  provided.   

Reported  Time  M    AN  1/8 

This  is  the  time  value  of  original  interchange  or  functional  group 

Cite  the  time  appearing  in  ISAIO  of  the  interchange  for  which  delivery  notice 
is  being  provided 

Reported  Interchange  Sender  ID  Qualifier  M    AN  1/4 

This  is  the  sender  ID  qualifier  value  appearing  in  original  interchange 

Cite  the  value  appearing  in  ISA05  of  the  interchange  for  which  delivery 
notice  is  being  provided. 
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Must  Use  TA309 


Must  Use  TA310 


Must  Use  TA311 


Must  Use  TA312 


Must  Use  TA313 


Must  Use  TA314 


Not  Used  TA315 


Not  Used  TA316 


Not  Used  TA317 


Not  Used  TA318 


149  Reported  Sender  ID  M    AN  1/35 

This  is  the  sender  ID  value  of  original  interchange  or  functional  group 

Cite  the  value  appearing  in  ISA06  of  the  interchange  for  which  delivery 
notice  is  being  provided. 

150  Reported  Interchange  Receiver  ID  Qualifier  M    AN  1/4 

This  is  the  receiver  ID  qualifier  value  appearing  in  original  interchange 
Cite  the  value  appearing  in  ISA07  of  the  interchange  for  which  delivery 
notice  is  being  provided. 

151  Reported  Receiver  ID  M    AN  1/35 
This  is  the  receiver  ID  value  of  original  interchange  or  functional  group 

Cite  the  value  appearing  in  ISA08  of  the  interchange  for  which  delivery 
notice  is  being  provided, 

140  Action  Code  M  ID  2/2 
This  is  a  code  indicating  the  action  taken  on  the  interchange  or  functional 
group  by  the  service  request  handler  or  the  receiver 

AK  Transfer  to  the  Next  Service  Request  Handler  has  been 

Acknowledged 

BH  Transfer  to  Service  Request  Handler  not  Capable  of 

Reporting  Further  Status 
DL  Delivered  Interchange  by  Service  Request  Handler 

PU  Purged  by  Interchange  Receiver 

RD  Redirected  by  Service  Request  Handler  to  an  Alternate 

Receiver  as  Identified  in  the  Reference  Code 
RF  Refused  by  Interchange  Receiver 

RJ  Rejected  by  Service  Request  Handler;  See  Error  Reason 

Code  for  Cause 
RT  Retrieved  Interchange  by  Receiver 

TR  Transferred  to  Next  Service  Request  Handler  by 

Service  Request  Handler,  but  not  yet  Acknowledged 

141  Action  Date  M    DT  6/6 
This  is  the  UTC  date  when  the  service  request  handler  took  action  on  the 
reported  interchange  or  functional  group 

Express  the  UTC  (previously  known  as  GMT)  date  in  a  six-position 
(YYMMDD)  format. 

142  Action  Time  M    TM  4/6 

This  is  the  UTC  time  when  the  service  request  handler  took  action  on  the 
reported  interchange  or  functional  group 

Express  the  UTC  (previously  known  as  GMT)  time  in  a  four-position 
(HHMM)  format. 

140  Action  Code  O     ID  2/2 

This  is  a  code  indicating  the  action  taken  on  the  interchange  or  functional 

group  by  the  service  request  handler  or  the  receiver 

Refer  to  003070  Data  Element  Dictionary  for  acceptable  code  values. 

141  Action  Date  O     DT  6/6 

This  is  the  UTC  date  when  the  service  request  handler  took  action  on  the 
reported  interchange  or  functional  group 

142  Action  Time  O     TM  4/6 
This  is  the  UTC  time  when  the  service  request  handler  took  action  on  the 
reported  interchange  or  functional  group 

152  First  Reference  ID  Qualifier  O     AN  1/4 
This  is  the  ID  qualifier  appearing  in  original  interchange 
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Not  Used  TA319 

Not  Used  TA320 
Not  Used  TA321 

TA322 


TA323 


Not  Used  TA324 


Not  Used  TA325 


Not  Used  TA326 


Not  Used  TA327 


153  First  Reference  ID  O     AN  1/14 

This  contains  information  from  the  original  interchange,  as  defmed  by  the  First 
Reference  ID  Quahfier  data  element 

154  Second  Reference  ID  Qualifier  O     AN  1/4 
This  contains  ID  qualifier  information  appearing  in  original  interchange 

155  Second  Reference  ID  O     AN  1/14 
This  contains  information  from  the  original  interchange,  as  defmed  by  the 
Second  Reference  ID  Qualifier  data  element 

156  Reference  Code  Qualifier  X     ID  2/2 

This  is  a  code  defming  the  information  contained  in  the  Reference  Code  data 
element 

IfTA312  is  code  RD,  use  TA322  and  TA323  to  identify  the  organization  to 
which  the  interchange  was  redirected. 

05  ID  of  Alternate  Receiver  to  which  Interchange  Has 

Been  Redirected 

157  Reference  Code  X     AN  1/35 

This  contains  reference  information  exchanged  between  service  request 
handlers  concerning  the  reported  interchange  as  defined  by  the  corresponding 
Reference  Code  Qualifier  data  element 

'Cite  the  identifier  of  the  organization  to  which  the  interchange  was 
redirected.  The  organization  shall  be  identified  via  a  unique  identifier  from 
one  of  the  sources  listed  as  allowable  codes  in  the  IS  AOS  definition  in  section 
10.6  of  the  Federal  EDI  Guidelines.  The  Data  Universal  Numbering  System 
(D-U-N-S)  number  and  D-U-N-S  +4  are  the  preferred  identifiers. 

156  Reference  Code  Qualifier  X     ID  2/2 
This  is  a  code  defining  the  information  contained  in  the  Reference  Code  data 
element 

157  Reference  Code  X     AN  1/35 

This  contains  reference  information  exchanged  between  service  request 
handlers  concerning  the  reported  interchange  as  defined  by  the  corresponding 
Reference  Code  Qualifier  data  element 

156  Reference  Code  Qualifier  X     ID  2/2 
This  is  a  code  defming  the  information  contained  in  the  Reference  Code  data 
element 

157  Reference  Code  X     AN  1/35 

This  contains  reference  information  exchanged  between  service  request 
handlers  concerning  the  reported  interchange  as  defined  by  the  corresponding 
Reference  Code  Qualifier  data  element 
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Segment: 

Usage: 
Max  Use: 
Purpose: 
Syntax  Notes: 
Semantic  Notes: 

Comments: 


Notes: 


GS  Functional  Group  Header 

Mandatory 
1 

To  indicate  the  beginning  of  a  functional  group  and  to  provide  control  information 

The  data  interchange  control  number  GS06  in  this  header  must  be  identical  to  the  same 
data  element  in  the  associated  functional  group  trailer,  GE02. 

A  functional  group  of  related  transaction  sets,  within  the  scope  of  X12  standards,  consists 
of  a  collection  of  similar  transaction  sets  enclosed  by  a  functional  group  header  and  a 
functional  group  trailer. 

1.  Use  to  identify  the  functional  group  containing  one  or  more  related  transactions. 

2.  Use  to  identify  the  specific  implementation  convention  with  which  the  transaction 
sets  contained  within  the  functional  group  envelope  comply. 

3.  The  version  and  release  of  the  GS  segment  must  be  the  same  as  the  version  and 
release  of  the  transactions  that  follow  it  as  specified  in  the  Version  /Release  /Industry 
Identifier  Code  (GS08). 


4.  The  GS  segment  represented  here  is  valid  for  version  2003. 


Data  Element  Summary 

Name  Attributes 
Functional  Identifier  Code  M    ID  2/2 

Code  identifying  a  group  of  application  related  transaction  sets 

Cite  any  valid  code  defined  for  data  element  479  in  the  ASC  XI 2  2003 
Standards  Data  Element  Dictionary  providing  a  Federal  implementation 
convention  exists  for  the  cited  transaction  set. 

Application  Sender's  Code  M    AN  2/12 

Code  identifying  party  sending  transmission  . 

1.  Cite  the  sending  application 's  identifier.  This  identifier  must  be  unique 
within  the  domain  of  the  sending  application 's  translation  point.  Use  of  a 
Dun  and  Bradstreet  number  (DUNS)  is  recommended  to  provide  universal 
uniqueness. 

2.  Transmit  the  required  number  of  characters  without  leading  or  trailing 
blanks. 

Must  Use    GS03  124      Application  Receiver's  Code  M    AN  2/12 

Code  identifying  party  receiving  transmission 

1.  Cite  the  receiving  application 's  identifier.  This  identifier  must  be  unique 
within  the  domain  of  the  receiving  application 's  translation  point  Use  of  a 
Dun  and  Bradstreet  number  (DUNS)  is  recommended  to  provide  universal 
uniqueness. 

2.  Transmit  the  required  number  of  characters  without  leading  or  trailing 
blanks. 

3.  If  the  group  contains  PUBLIC  transactions,  enter  the  literal  string 


Ref.  Data 
Des.  Element 
Must  Use    GSOl  479 


Must  Use    GS02  142 
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I'PUBLrC'. 

Must  Use    GS04  29       Data  Interchange  Date  M    DT  6/6 

Date  sender  generated  a  functional  group  of  transaction  sets. 

1.  Enter  the  UTC  (previously  known  as  GMT)  date  that  this  segment  was 
created, 

2.  Express  the  date  in  a  six-position  (YYMMDD)  format. 

Must  Use    GS05  30       Data  Interchange  Time  M    TM  4/4 

Time  (HHMM)  when  the  sender  generated  a  functional  group  of  transaction 
sets  (local  time  at  sender's  location). 

L  Enter  the  UTC  (previously  known  as  GMT)  lime  thai  this  segment  was 
created. 

2.  Express  the  time  in  a  four-position  (HHMM)  format. 
Must  Use    GS06  28       Data  Interchange  Control  Number  M    NO  1/9 

Assigned  number  originated  and  maintained  by  the  sender 
%  Originating  activities  may  use  any  numbering  scheme  consistent  with 
Itheir  business  practices. 

12.  The  scheme  must  provide  sufficient  uniqueness  to  identify  each 
functional  group.  The  Group  Control  Number  value,  together  with  the 
Application  Sender's  and  Receiver's  Codes,  shall  be  unique  within  an 
extended  time  frame  -  such  as  a  year. 

Responsible  Agency  Code  M    ID  1/2 

Code  used  in  conjunction  with  Data  Element  480  to  identify  the  issuer  of  the 
standard 

X  Accredited  Standards  Committee  X12 

Version  /  Release  /  Industry  Identifier  Code  M    AN  1/12 

Code  indicating  the  version,  release,  subrelease,  and  industry  identifier  of  the 
EDI  standard  being  used.  Positions  1-3,  Major  Version  Number;  Positions  4- 
6,  Release  Level  of  Version;  Positions  7-12,  Industry  or  Trade  Association  ID 
(optionally  assigned  by  user). 


Each  Federal  and  DoD  Implementation  Convention,  based  on  an  ANSI  ASC 
XI 2  transaction  set,  used  by  the  government  has  a  unique  identifier  specified 
as  follow: 

Positions  1  through  6: 

ANSI  ASC  X12  Version  and  Release 
number  (e.g.  003010)  upon  which  the 
IC  is  based. 

Position  7: 

Organizational  Scope 
F  =  Federal 
D=DOD 

G  =  Government  (transitional) 

Positions  8  through  10: 

Transaction  Set  Identifier  Code 
(e.g.  850). 

Position  11: 

Variant:  A  character  used  to 
differentiate  between  different 

Must  Use    GS07  455 


Must  Use    GS08  480 
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functional  implementations  of  the 
same  transaction  set. 

If  the  convention  is  not  a  variant,  an 
underscore  (_)  will  appear  in  this 
position. 

Position  12:  A  sequential  number  starting  with  0 

and  incremented  by  1  each  time  the 
implementation  convention  is  revised. 
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Segment: 

Usage: 
Max  Use: 
Purpose: 
Syntax  Notes: 
Semantic  Notes: 

Comments: 


Notes: 


GS  Functional  Group  Header 

Mandatory 
1 

To  indicate  the  beginning  of  a  functional  group  and  to  provide  control  information 

The  data  interchange  control  number  GS06  in  this  header  must  be  identical  to  the  same 
data  element  in  the  associated  functional  group  trailer,  GE02. 

A  functional  group  of  related  transaction  sets,  within  the  scope  of  X12  standards,  consists 
of  a  collection  of  similar  transaction  sets  enclosed  by  a  functional  group  header  and  a 
functional  group  trailer. 

1.  Use  to  identify  the  functional  group  containing  one  or  more  related  transactions. 

2.  Use  to  identify  the  specific  implementation  convention  with  which  the  transaction 
sets  contained  within  the  functional  group  envelope  comply. 

3.  The  version  and  release  of  the  GS  segment  must  be  the  same  as  the  version  and 
release  of  the  transactions  that  follow  it  as  specified  in  the  Version  /  Release  /  Industry 
Identifier  Code  (GS08). 


4.  The  GS  segment  represented  here  is  valid  for  version  3010. 


Ref. 
Pes. 

Must  Use  GSOl 


Must  Use  GS02 


Must  Use  GS03 


Data 
Element 
479 


142 


124 


Data  Element  Summary 

Name  Attributes 
Functional  Identifier  Code  M    ID  2/2 

Code  identifying  a  group  of  application  related  transaction  sets 
Cite  any  valid  code  defined  for  data  element  479  in  the  ASC  XI 2  3010 
Standards  Data  Element  Dictionary  providing  a  Federal  implementation 
convention  exists  for  the  cited  transaction  set. 

Application  Sender's  Code  M    AN  2/12 

Code  identifying  party  sending  transmission  . 

1.  Cite  the  sending  application 's  identifier.  This  identifier  must  be  unique 
within  the  domain  of  the  sending  application 's  translation  point.  Use  of  a 
Dun  and  Bradstreet  number  (DUNS)  is  recommended  to  provide  universal 
uniqueness. 

2.  Transmit  the  required  number  of  characters  without  leading  or  trailing 
hlanks. 

Application  Receiver's  Code  M    AN  2/12 

Code  identifying  party  receiving  transmission 

/.  Cite  the  receiving  application 's  identifier.  This  identifier  must  be  unique 
within  the  domain  of  the  receiving  application 's  translation  point  Use  of  a 
Dun  and  Bradstreet  number  (DUNS)  is  recommended  to  provide  universal 
uniqueness. 

2.  Transmit  the  required  number  of  characters  without  leading  or  trailing 
blanks. 
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J.  If  the  group  contains  PUBLIC  transactions,  enter  the  literal  string 
'PUBLIC. 

29       Group  Date  M    DT  6/6 

Date  sender  generated  a  functional  group  of  transaction  sets. 

i.  Enter  the  UTC  (previously  known  as  GMT)  date  that  this  segment  was 
created. 


Must  Use  GS05 


2.  Express  the  date  in  a  six-position  (YYMMDD)  format. 
30       Group  Time  M    TM  4/4 

Time  (HHMM)  when  the  sender  generated  a  functional  group  of  transaction 
sets  (local  time  at  sender's  location). 

/.  Enter  the  UTC  (previously  known  as  GMT)  time  that  this  segment  was 
created. 


Must  Use  GS06 


2.  Express  the  time  in  a  four-position  (HHMM)  format. 
28       Group  Control  Number  M    NO  1/9 

Assigned  number  originated  and  maintained  by  the  sender 

1.  Originating  activities  may  use  any  numbering  scheme  consistent  with 

their  business  practices. 


Must  Use  GS07 


Must  Use  GS08 


2.  The  scheme  must  provide  sufficient  uniqueness  to  identify  each 
functional  group.  The  Group  Control  Number  value,  together  with  the 
Application  Sender's  and  Receiver's  Codes,  shall  be  unique  within  an 
extended  time  frame  -  such  as  a  year. 
455      Responsible  Agency  Code  M    ID  1/2 

Code  used  in  conjunction  with  Data  Element  480  to  identify  the  issuer  of  the 
standard 

X  Accredited  Standards  Committee  XI 2 

480      Version  /  Release  /  Industry  Identifier  Code  M    AN  1/12 

Code  indicating  the  version,  release,  subrelease,  and  industry  identifier  of  the 
EDI  standard  being  used.  Positions  1-3,  Major  Version  Number;  Positions  4- 
6,  Release  Level  of  Version;  Positions  7-12,  Industry  or  Trade  Association  ID 
(optionally  assigned  by  user). 


Each  Federal  and  DoD  Implementation  Convention,  based  on  an  ANSI  ASC 
X12  transaction  set,  used  by  the  government  has  a  unique  identifier  specified 
as  follow: 

Positions  1  through  6: 

ANSI  ASC  XI 2  Version  and  Release 
number  (e.g.  003010)  upon  which  the 
IC  is  based. 

Position  7: 

Organizational  Scope 
F  =  Federal 
D  =  DOD 

G  =  Government  (transitional) 

Positions  8  through  10: 

Transaction  Set  Identifier  Code 
(e.g.  850). 

Position  11: 

Variant:  A  character  used  to 
differentiate  between  different 
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functional  implementations  of  the 
same  transaction  set. 

If  the  convention  is  not  a  variant,  an 
underscore  (_)  will  appear  in  this 
position. 

Position  12:  A  sequential  number  starting  with  0 

and  incremented  by  1  each  time  the 
implementation  convention  is  revised. 


Segment: 

Usage: 
Max  Use: 
Purpose: 
Syntax  Notes: 
Semantic  Notes: 


Comments: 


Notes: 


GS  Functional  Group  Header 

Mandatory 
1 

To  indicate  the  beginning  of  a  functional  group  and  to  provide  control  information 

1  GS04  is  the  group  date. 

2  GS05  is  the  group  time. 

3  The  data  interchange  control  number  GS06  in  this  header  must  be  identical  to  the 
same  data  element  in  the  associated  functional  group  trailer,  GE02. 

1  A  functional  group  of  related  transaction  sets,  within  the  scope  of  X12  standards, 
consists  of  a  collection  of  similar  transaction  sets  enclosed  by  a  fianctional  group 
header  and  a  fiinctional  group  trailer. 

1.  Use  to  identify  the  functional  group  containing  one  or  more  related  transactions. 

2.  Use  to  identify  the  specific  implementation  convention  with  which  the  transaction 
sets  contained  within  the  functional  group  envelope  comply. 

3.  The  version  and  release  of  the  GS  segment  must  be  the  same  as  the  version  and 
release  of  the  transactions  that  follow  it  as  specified  in  the  Version  /  Release  /  Industiy 
Identifier  Code  (GS08). 


4.  The  GS  segment  represented  here  is  valid  for  version  3040  through  3070. 


Must  Use 


Ref. 
Pes. 
GSOl 


Must  Use  GS02 


Data 
Element 
479 


142 


Data  Element  Summary 

Name  Attributes 
Functional  Identifier  Code  M    ID  2/2 

Code  identifying  a  group  of  application  related  transaction  sets 

Cite  any  valid  code  defined  for  data  element  479  in  the  ASC  XI 2  3040 
through  3070  (as  applicable)  Standards  Data  Element  Dictionary  providing 
a  Federal  implementation  convention  exists  for  the  cited  transaction  set. 
Application  Sender's  Code  M    AN  2/15 

Code  identifying  party  sending  transmission;  codes  agreed  to  by  trading 
partners 

1.  Cite  the  sending  application 's  identifier.  This  identifier  must  be  unique 
within  the  domain  of  the  sending  application 's  translation  point.  Use  of  a 
Dun  and  Bradstreet  number  (DUNS  or  DUNS+4)  is  recommended  to  provide 
universal  uniqueness. 
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2.  Transmit  the  required  number  of  characters  without  leading  or  trailing 
blanks. 

Must  Use    GS03  124      Application  Receiver's  Code  M    AN  2/15 

Code  identifying  party  receiving  transmission.  Codes  agreed  to  by  trading 
partners 

1.  Cite  the  receiving  application 's  identifier.  This  identifier  must  be  unique 
within  the  domain  of  the  receiving  application 's  translation  point.  Use  of  a 
Dun  and  Bradstreet  number  (D-U-N-S  or  D-U-N-S+4)  is  recommended  to 
provide  universal  uniqueness. 

2.  Transmit  the  required  number  of  characters  without  leading  or  trailing 
blanks. 


3.  If  the  group  contains  PUBLIC  transactions,  enter  the  literal  string 
'PUBLIC. 

Must  Use    GS04  373      Date  M    DT  6/6 

Date  (YYMMDD) 

L  Enter  the  UTC  (previously  known  as  GMT)  date  that  this  segment  was 
created. 


2.  Express  the  date  in  a  six-position  (YYMMDD)  format. 
Must  Use    GS05  337      Time  M    TM  4/8 

Time  expressed  in  24-hour  clock  time  as  follows:  HHMM,  or  HHMMSS,  or 
HHMMSSD,  or  HHMMSSDD,  where  H  =  hours  (00-23),  M  =  minutes  (00- 
59),  S  =  integer  seconds  (00-59)  and  DD  =  decimal  seconds;  decimal  seconds 
are  expressed  as  follows:  D  =  tenths  (0-9)  and  DD  =  hundredths  (00-99) 
7.  Enter  the  UTC  (previously  known  as  GMT)  time  that  this  segment  was 
created. 


2.  Express  the  time  in  a  four-position  (HHMM)  format. 
Must  Use    GS06  28       Group  Control  Number  M    NO  1/9 

Assigned  number  originated  and  maintained  by  the  sender 

L  Originating  activities  may  use  any  numbering  scheme  consistent  with 
their  business  practices. 

2.  The  scheme  must  provide  sufficient  uniqueness  to  identify  each 
functional  group.  The  Group  Control  Number  value,  together  with  the 
Application  Sender's  and  Receiver's  Codes,  shall  be  unique  within  an 
extended  time  frame  -  such  as  a  year. 
Must  Use    GS07  455      Responsible  Agency  Code  M    ID  1/2 

Code  used  in  conjunction  with  Data  Element  480  to  identify  the  issuer  of  the 
standard 

X  Accredited  Standards  Committee  X12 

Must  Use    GS08  480      Version  /  Release  /  Industry  Identifier  Code  M    AN  1/12 

Code  indicating  the  version,  release,  subrelease,  and  industry  identifier  of  the 
EDI  standard  being  used,  including  the  GS  and  GE  segments;  if  code  in 
DE455  in  GS  segment  is  X,  then  in  DE  480  positions  1-3  are  the  version 
number;  positions  4-6  are  the  release  and  subrelease,  level  of  the  version;  and 
positions  7-12  are  the  industry  or  trade  association  identifiers  (optionally 
assigned  by  user);  if  code  in  DE455  in  GS  segment  is  T,  then  other  formats  are 
allowed 
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Each  Federal  and  DoD  Implementation  Convention,  based  on  an  ANSI  ASC 
XI 2  transaction  set,  used  by  the  government  has  a  unique  identifier  specified 
as  follow: 

Positions  1  through  6: 

ANSI  ASC  XI 2  Version  and  Release 
number  (e.g.  003010)  upon  which  the 
IC  is  based. 

Position  7: 

Organizational  Scope 
F  =  Federal 
D=DOD 

G  =  Government  (transitional) 

Positions  8  through  10: 

Transaction  Set  Identifier  Code 
(e.g.  850). 

Position  11: 

Variant:  A  character  used  to 
differentiate  between  different 
functional  implementations  of  the 
same  transaction  set 

If  the  convention  is  not  a  variant,  an 
underscore  (_)  will  appear  in  this 
position. 

Position  12: 

A  sequential  number  starting  with  0 
and  incremented  by  I  each  time  the 
implementation  convention  is  revised. 
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Segment: 

Usage: 
Max  Use: 
Purpose: 

Syntax  Notes: 

Semantic  Notes: 

Comments: 
Notes: 


SIS  Security  Header  Level  1 

Optional 
1 

To  initiate  the  beginning  of  a  secured  area  and  to  provide  the  parameters  needed  for 
authentication  or  encryption  of  a  functional  group 

1  If  either  S1S04  or  SI  805  is  present,  then  the  other  is  required. 

2  If  any  of  S 1 806  S 1 S07  S 1 S08  or  S 1 809  is  present,  then  all  are  required. 
1     If  81  SOI  is  "AA"  or  "BB",  81804  is  required. 

If  SlSOl  is  ""BB"  or  "EE",  81806  is  required. 

1.  X9  has  a  minimum  length  of  4  characters  for  S1S02  (the  security  originator);  no 
mechanism,  or  registration  method  is  provided  by  X9  or  X12  to  guarantee  the 
uniqueness  of  the  identifier 

2.  X9  has  a  minimum  length  of  4  characters  for  S1S03  (the  security  recipient);  no 
mechanism,  or  registration  method  is  provided  by  X9  or  XI 2  to  guarantee  the 
uniqueness  of  the  identifier 

3.  The  SIS  segment  represented  here  is  only  valid  for  versions  3040  and  3050. 


Ref. 
Pes. 

Must  Use  SlSOl 


Must  Use  S1S02 


Data 
Element 
990 


824 


Data  Element  Summary 

Name  Attributes 
Security  Type  M    ID  2/2 

Code  identifying  the  security  algorithms  and  methods  employed  for  this  level 
of  interchange. 

EE  Encryption,  No  Authentication 

Security  Originator  Name  M    AN  4/16 

Unique  designation  (identity)  of  the  cryptographic  process  that  performs 
authentication  or  encryption  on  data  to  be  interchanged,  or  originates  a 
cryptographic  service  message 


Must  Use    SI  SOS 


S1S04 


S1S05 


Note:  X9  has  a  minimum  length  of  4  characters  for  the  security  originator;  no 
mechanism,  or  registration  method  is  provided  by  X9  or  XI 2  to  guarantee  the 
uniqueness  of  the  identifier 
825      Security  Recipient  Name  M    AN  4/16 

Unique  designation  (identity)  of  the  cryptographic  process  that  performs 
authentication  or  decryption  on  received  data,  or  is  the  destination  of  a 
cryptographic  service  message 

Note:  X9  has  a  minimum  length  of  4  characters  for  the  security  recipient;  no 
mechanism,  or  registration  method  is  provided  by  X9  or  X12  to  guarantee  the 
uniqueness  of  the  identifier 

991  Authentication  Key  Name  X     AN  1/16 
Name  of  the  key  used  for  authentication.  This  name  is  mutually  known  to  the 
security  originator  and  the  security  recipient,  is  unique  for  this  relationship, 
and  allows  a  particular  key  to  be  specified. 

992  Authentication  Service  Code  X     ID  1/1 


Authentication  option 


ANSI  X9.9  Binary  Data 

ANSI  X9.9  Coded  Character  Set,  Entire  Message,  No 
Editing 
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S1S06 


S1S07 


993 


994 


S1S08 


S1S09 


995 


996 


Standard  value  for  ANSI  X9.17  authentication,  with  the 
data  element  separator  expressed  as  an  asterisk  and  the 
segment  terminator  expressed  as  a  linefeed  character  for 
the  calculation  of  the  message  authentication  code 
(MAC) 

Encryption  Key  Name  X     AN  1/16 

Name  of  the  key  used  for  encryption.  This  name  is  mutually  known  to  the 
security  originator  and  the  security  recipient,  is  unique  for  this  relationship, 
and  allows  a  particular  key  to  be  specified. 

Encryption  Service  Code  X     ID  1/3 

Coded  values  representing  options  for  encryption  processing.  The  code  defines 
the  encryption  mode  and  the  transmission  filter  specification  for  filtering 
binary  ciphertext  data  into  transmittable  text. 

2 1  ANSI  X9.23  Cipher  Block  Chaining  (CBC), 
Hexadecimal  Filter 

22  ANSI  X9.23  Cipher  Block  Chaining  (CBC),  ASCII 
Filter 

41  ANSI  X9.23  CFB-8  (Cipher  Feedback),  Hexadecimal 
Filter 

42  ANSI  X9.23  CFB-8  (Cipher  Feedback),  ASCII  Filter 

Length  of  Data  (LOD)  X     N  1/18 

Length  of  data  is  the  number  of  character  positions  of  the  encrypted,  filtered 
text. 

Initialization  Vector  (IV)  X     AN  16/16 

The  archival  representation  of  a  64-bit  value  expressed  in  hexadecimal 
notation  as  16  ASCII  characters  from  the  set  of  characters  (0..9,  A..F);  the  64- 
bit  value  is  used  as  a  starting  point  for  encryption  of  a  data  sequence  to 
increase  security  by  introducing  cryptographic  variance  and  to  synchronize 
cryptographic  equipment;  a  new  Initialization  Vector  (IV)  shall  be  used  for 
each  message;  the  IV  shall  not  be  intentionally  reused;  the  64-bit  binary  value, 
not  its  ASCII  representation,  is  used  for  the  cryptographic  process;  in  the 
interchange  process,  the  resultant  encrypted  and  filtered  64-bit  IV  is  sent;  the 
hexadecimal  notation  is  the  representation  for  archiving  purposes;  the  IV  shall 
be  a  random  or  pseudo-random  number;  when  encrypted,  the  IV  must  be 
decrypted  using  the  Electronic  Code  Book  (ECB)  mode  and  the  same  key  used 
to  encrypt  the  message 
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Segment: 

Usage: 
Max  Use: 
Purpose: 

Syntax  Notes: 


SIS  Security  Header  Level  1 

Optional 
1 

To  initiate  the  beginning  of  a  secured  area  and  to  provide  the  parameters  needed  for 
authentication  or  encryption  of  a  functional  group 


1  If  either  S 1 804  or  S 1 805  is  present,  then  the  other  is  required. 

2  If  any  of  8 1 806  8 1 807  8 1 808  or  S 1 809  is  present,  then  all  are  required. 

3  If  either  C03204  or  C03205  is  present,  then  the  other  is  required. 

4  If  either  C03206  or  C03207  is  present,  then  the  other  is  required. 
Semantic  Notes:      1     If  81  SOI  is  "AA",  "BB",  "AC"  or  "BC",  then  81804  is  required. 

If  81  SOI  is  "BB",  "EE",  "AC"  or  "EC",  then  81806  is  required. 
Comments:      1     X9  has  a  required  minimum  length  of  four  characters  for  81802  (security  originator). 

No  mechanism,  or  registration  method,  is  provided  by  X9  or  X12  to  guarantee 
uniqueness  of  the  identifier. 

2  X9  has  a  required  minimum  length  of  four  characters  for  SI 803  (security  recipient). 
No  mechanism,  or  registration  method,  is  provided  by  X9  or  XI 2  to  guarantee 
uniqueness  of  the  identifier. 

3  In  81804,  the  special  name  "01234567890ABCDEF"  is  reserved  for  the  hexadecimal 
value  01234567890ABCDEF  (i.e.,  a  fixed,  nonsecret  value)  to  provide  a  well-known 
value  for  data-integrity  testing  only. 

Notes:       /.  X9  has  a  minimum  length  of  4  characters  for  S1S02  (the  security  originator);  no 
mechanism,  or  registration  method  is  provided  byX9  or  XI 2  to  guarantee  the 
uniqueness  of  the  identifier 

2.  X9  has  a  minimum  length  of  4  characters  for  S1S03  (the  security  recipient);  no 
mechanism,  or  registration  method  is  provided  byX9  or  XI 2  to  guarantee  the 
uniqueness  of  the  identifier 

3.  The  SIS  segment  represented  here  is  only  valid  for  versions  3060  and  3070. 


Data  Element  Summary 


Ref. 
Pes. 

Must  Use  SlSOl 


Must  Use  S1S02 


S1S03 


Data 
Element 
990 


824 


825 


Name 

Security  Type 


Attributes 


M    ID  2/2 

Code  identifying  the  security  algorithms  and  methods  applied  for  this  level  of 
interchange 

EC  No  Authentication,  Compression,  Encryption 

EE  No  Authentication,  No  Compression,  Encryption 

Security  Originator  Name  M    AN  1/64 

Unique  designation  (identity)  of  the  cryptographic  process  that  performs 
authentication  or  encryption  on  data  to  be  interchanged,  or  originates  a 
cryptographic  service  message 

Note:  X9  has  a  minimum  length  of  4  characters  for  the  security  originator;  no 
mechanism,  or  registration  method  is  provided  by  X9  or  X12  to  guarantee  the 
uniqueness  of  the  identifier 

Security  Recipient  Name  O     AN  1/64 

Unique  designation  (identity)  of  the  cryptographic  process  that  performs 
authentication  or  decryption  on  received  data,  or  is  the  destination  of  a 
cryptographic  service  message 

Note:  X9  has  a  minimum  length  of  4  characters  for  the  security  recipient;  no 
mechanism,  or  registration  method  is  provided  by  X9  or  X12  to  guarantee  the 
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S1S04 


S1S05 


S1S06 
Must  Use  C03101 


C03102 


C03103 

C03104 
C03105 
S1S07 
Must  Use  C03201 


uniqueness  of  the  identifier 

991  Authentication  Key  Name  X     AN  1/64 

Name  of  the  key  used  for  authentication;  this  name  is  mutually  known  to  the 
security  originator  and  the  security  recipient,  is  unique  for  this  relationship, 
and  is  intended  to  allow  the  changing  of  the  key  from  time  to  time 

Note:  The  special  key  name  "0123456789ABCDEF"  is  reserved  for  the 
hexidecimal  value  0123456789ABCDEF  (i.e.  a  fixed  non-secret  value)  to 
provide  a  well-known  value  for  data  integrity  testing  only) 

992  Authentication  Service  Code  X     ID  1/1 
Authentication  options 

4  MD5  Hash 

5  SHA  Hash 

C031     Encryption  Key  Information  X 
Information  needed  to  identify  or  obtain  the  encryption  key 

993  Encryption  Key  Name  M    AN  1/64 
Name  of  the  key  used  for  encryption;  this  name  is  mutually  known  to  the 
security  originator  and  the  security  recipient,  is  unique  for  this  relationship, 
and  is  intended  to  allow  the  changing  of  the  key  from  time  to  time 

Note:  If  any  of  the  optional  fields  are  present,  the  Key  Name  should  contain 
either  "PUBLIC"  if  a  public  key  is  being  used  to  encrpyt  the  one-time  key  or 
the  actual  name  of  the  asymmetric  key-encrypting-key  used  to  encrypt  the  one- 
time key. 

1564  Protocol  ID  O     ID  3/3 

Code  specifying  protocol  used  to  encrypt  the  session  key 
KEA  Key  Encryption  Algorithm 

RSA  RSA  Algorithm 

1565  Look-up  Value  O  AN  1/512 
Value  used  to  identify  a  certificate  containing  the  public  key  used  to  encrypt 
the  one-time  key 

1566  Keying  Material  O     AN  1/512 

Additional  material  required  for  decrypting  the  one-time  key 

1567  One-time  Encryption  Key  O  AN  1/512 
Hexadecimally  filtered  encrypted  one-time  key 

C032     Encryption  Service  Information  X 

Information  required  by  the  encryption  operation 

994  Encryption  Service  Code  M    ID  1/3 
Coded  values  representing  options  for  encryption  processing,  including  the  use 
of  compression  and  filtering;  the  code  either  defines  the  encryption  mode  and 
the  transmission  filter  specification  for  filtering  binary  data  into  transmittable 
text  or  specifics  that  the  following  subelements  define  these  values 

2 1  ANSI  X9.23  Cipher  Block  Chaining  (CBC), 
Hexadecimal  Filter 

22  ANSI  X9.23  Cipher  Block  Chaining  (CBC),  ASCII 
Filter 

4 1  ANSI  X9.23  CFB-8  (Cipher  Feedback),  Hexadecimal 

Filter 
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42  ANSI  X9.23  CFB-8  (Cipher  Feedback),  ASCII  Filter 

C03202  1568      Algorithm  ID  O     ID  3/3 

Algorithm  used  for  Encryption 
DE3  Triple  DEA 

DES  Data  Encryption  Standard  (Same  as  DEA) 

As  specified  in  FIPS  46-2. 
SKJ  Skipjack 
C03203  1569      Algorithm  Mode  of  Operation  O     ID  3/3 

Mode  of  Operation  of  the  Encryption  Algorithm 
CBC  Cipher  Block  Chaining 

C03204  1570      Filter  ID  Code  X     ID  3/3 

Code  specifying  the  type  of  filter  used  to  convert  data  code  values 
ASB  ASCII-Baudot  Filter 

ASC  ASCII  Filter 

HDC  Hexadecimal  Filter 

UUE  Uuencoding 
ZZZ  Mutually  Defined 

Use  to  indicate  Base  64. 

C03205  799      Version  Identifier  ^  ^^^^ 

Revision  level  of  a  particular  format,  program,  technique  or  algorithm 
C03206  1571      Compression  ID  X     ID  3/3 

Type  of  Compression  Used 

913  X9E13  Compression  as  defined  by  X9.32 

ZZZ  Mutually  Defined 

Use  to  indicate  that  each  block  has  been  compressed 
by  using  a  combination  of  the  Lempel-Ziv  LZ77 
algorithm  and  Huffman  coding,  in  accordance  with 
the  Internet  Engineering  Task  Force  (IETF)  Request 
for  Comments  (RFC)  1951  format. 
C03207  799      Version  Identifier  X     AN  1/30 

Revision  level  of  a  particular  format,  program,  technique  or  algorithm 
Cite  the  version  of  the  compression  algorithm  cited  in  S1S07  (C03206) 
above. 

51508  995      Length  of  Data  X     N  1/18 

Length  of  data  is  the  number  of  character  positions  of  the  compressed  or 
encrypted/filtered  text;  when  data  is  plain  text,  this  field  shall  be  absent 

51509  996      Initialization  Vector  X     AN  16/16 

The  archival  representation  of  a  64-bit  value  expressed  in  hexadecimal 
notation  as  16  ASCII  characters  from  the  set  of  characters  (0..9,  A..F);  the  64- 
bit  value  is  used  as  a  starting  point  for  encryption  of  a  data  sequence  to 
increase  security  by  introducing  cryptographic  variance  and  to  synchronize 
cryptographic  equipment;  a  new  Initialization  Vector  (IV)  shall  be  used  for 
each  message;  the  IV  shall  not  be  intentionally  reused;  the  64-bit  binary  value, 
not  its  ASCII  representation,  is  used  for  the  cryptographic  process;  in  the 
interchange  process,  the  resultant  encrypted  and  filtered  64-bit  IV  is  sent;  the 
hexadecimal  notation  is  the  representation  for  archiving  purposes;  the  IV  shall 
be  a  random  or  pseudo-random  number;  when  encrypted,  the  IV  must  be 
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decrypted  using  the  Electronic  Code  Book  (ECB)  mode  and  the  same  key  used 
to  encrypt  the  message 
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Segment:      SIS  Security  Header  Level  2 

Usage:  Optional 
Max  Use:  1 

Purpose:      To  initiate  the  beginning  of  a  secured  area  and  to  provide  the  parameters  needed  for 
authentication  or  encryption  of  a  transaction  set 
Syntax  Notes:      1     If  either  S2S04  or  S2S05  is  present,  then  the  other  is  required. 

2     If  any  of  S2S06  S2S07  S2S08  or  S2S09  is  present,  then  all  are  required. 
Semantic  Notes:      1     If  S2S01  is  "AA"  or  "BB",  S2S04  is  required. 

If  S2S01  is  "BB"  or  '"EE",  S2S06  is  required. 

Comments: 

Notes:      1.  X9  has  a  minimum  length  of  4  characters  for  S2S02  (the  security  originator);  no 
mechanism,  or  registration  method  is  provided  byX9  orX12  to  guarantee  the 
uniqueness  of  the  identifier 

2.  X9  has  a  minimum  length  of  4  characters  for  S2S03  (the  security  recipient);  no 
mechanism,  or  registration  method  is  provided  by  X9  or  XI 2  to  guarantee  the 
uniqueness  of  the  identifier. 

3.  The  S2S  segment  represented  here  is  only  valid  for  versions  3040  and  3050. 


Ref. 
Pes. 

Must  Use  S2S01 


Must  Use  S2S02 


Data 
Element 
990 


824 


Data  Element  Summary 

Name  Attributes 
Security  Type  M    ID  2/2 

Code  identifying  the  security  algorithms  and  methods  employed  for  this  level 
of  interchange. 

EE  Encryption,  No  Authentication 

Security  Originator  Name  M    AN  4/16 

Unique  designation  (identity)  of  the  cryptographic  process  that  performs 
authentication  or  encryption  on  data  to  be  interchanged,  or  originates  a 
cryptographic  service  message 


Must  Use  S2S03 


S2S04 

S2S05 
S2S06 


Note:  X9  has  a  minimum  length  of  4  characters  for  the  security  originator;  no 
mechanism,  or  registration  method  is  provided  by  X9  or  XI 2  to  guarantee  the 
uniqueness  of  the  identifier 
825      Security  Recipient  Name  M    AN  4/16 

Unique  designation  (identity)  of  the  cryptographic  process  that  performs 
authentication  or  decryption  on  received  data,  or  is  the  destination  of  a 
cryptographic  service  message 

Note:  X9  has  a  minimum  length  of  4  characters  for  the  security  recipient;  no 
mechanism,  or  registration  method  is  provided  by  X9  or  XI 2  to  guarantee  the 
uniqueness  of  the  identifier 

991  Authentication  Key  Name  X     AN  1/16 
Name  of  the  key  used  for  authentication.  This  name  is  mutually  known  to  the 
security  originator  and  the  security  recipient,  is  unique  for  this  relationship, 
and  allows  a  particular  key  to  be  specified. 

992  Authentication  Service  Code  X     ID  1/1 
Authentication  option 

993  Encryption  Key  Name  X     AN  1/16 
Name  of  the  key  used  for  encryption.  This  name  is  mutually  known  to  the 
security  originator  and  the  security  recipient,  is  unique  for  this  relationship, 
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S2S07 


994 


S2S08 


S2S09 


995 


996 


and  allows  a  particular  key  to  be  specified. 

Encryption  Service  Code  X     ID  1/3 

Coded  values  representing  options  for  encryption  processing.  The  code  defines 
the  encryption  mode  and  the  transmission  filter  specification  for  filtering 
binary  ciphertext  data  into  transmittable  text. 

2 1  ANSI  X9.23  Cipher  Block  Chaining  (CBC), 
Hexadecimal  Filter 

22  ANSI  X9.23  Cipher  Block  Chaining  (CBC),  ASCII 
Filter 

4 1  ANSI  X9.23  CFB-8  (Cipher  Feedback),  Hexadecimal 
Filter 

42  ANSI  X9.23  CFB-8  (Cipher  Feedback),  ASCII  Filter 
Length  of  Data  (LOD)  X     N  1/18 
Length  of  data  is  the  number  of  character  positions  of  the  encrypted,  filtered 
text. 

Initialization  Vector  (IV)  X     AN  16/16 

The  archival  representation  of  a  64-bit  value  expressed  in  hexadecimal 
notation  as  16  ASCII  characters  from  the  set  of  characters  (0..9,  A..F);  the  64- 
bit  value  is  used  as  a  starting  point  for  encryption  of  a  data  sequence  to 
increase  security  by  introducing  cryptographic  variance  and  to  synchronize 
cryptographic  equipment;  a  new  Initialization  Vector  (IV)  shall  be  used  for 
each  message;  the  IV  shall  not  be  intentionally  reused;  the  64-bit  binary  value, 
not  its  ASCII  representation,  is  used  for  the  cryptographic  process;  in  the 
interchange  process,  the  resultant  encrypted  and  filtered  64-bit  IV  is  sent;  the 
hexadecimal  notation  is  the  representation  for  archiving  purposes;  the  IV  shall 
be  a  random  or  pseudo-random  number;  when  encrypted,  the  IV  must  be 
decrypted  using  the  Electronic  Code  Book  (ECB)  mode  and  the  same  key  used 
to  encrypt  the  message 
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Segment: 

Usage: 
Max  Use: 
Purpose: 

Syntax  Notes: 


Semantic  Notes: 
Comments: 


S2S  Security  Header  Level  2 

Optional 
1 

To  initiate  the  beginning  of  a  secured  area  and  to  provide  the  parameters  needed  for 
authentication  or  encryption  of  a  transaction  set 


1  If  either  S2S04  or  S2S05  is  present,  then  the  other  is  required. 

2  If  any  of  S2S06  S2S07  S2S08  or  S2S09  is  present,  then  all  are  required. 

3  If  either  C03204  or  C03205  is  present,  then  the  other  is  required. 

4  If  either  C03206  or  C03207  is  present,  then  the  other  is  required. 
1     If  S2S01  is  "AA",  "BB",  "AC"  or  "BC",  then  S2S04  is  required. 

If  S2S01  is  "BB",  "EE",  "AC"  or  "EC",  then  S2S06  is  required. 

1  X9  has  a  required  minimum  length  of  four  characters  for  S2S02  (security  originator). 
No  mechanism,  or  registration  method,  is  provided  by  X9  or  XI 2  to  guarantee 
uniqueness  of  the  identifier. 

2  X9  has  a  required  minimum  length  of  four  characters  for  S2S03  (security  recipient). 
No  mechanism,  or  registration  method,  is  provided  by  X9  or  XI 2  to  guarantee 
uniqueness  of  the  identifier. 

3  In  S2S04  the  special  name  "01234567890ABCDEF"  is  reserved  for  the  hexadecunal 
value  01234567890ABCDEF  (i.e.,  a  fixed  nonsecret  value)  to  provide  a  well-known 
value  for  data-integrity  testing  only. 

Notes:       1.  X9  has  a  minimum  length  of  4  characters  for  S2S02  (the  security  originator);  no 
mechanism,  or  registration  method  is  provided  byX9  orXll  to  guarantee  the 
uniqueness  of  the  identifier 

2.  X9  has  a  minimum  length  of  4  characters  for  S2S03  (the  security  recipient);  no 
mechanism,  or  registration  method  is  provided  by  X9  or  XI 2  to  guarantee  the 
uniqueness  of  the  identifier. 

3.  The  S2S  segment  represented  here  is  only  valid  for  versions  3060  and  3070. 


Data  Element  Summary 


Ref. 
Pes. 

Must  Use  S2S01 


Must  Use  S2S02 


S2S03 


Data 
Element 
990 


824 


825 


Name 

Security  Type 


Attributes 


M    ID  2/2 

Code  identifying  the  security  algorithms  and  methods  applied  for  this  level  of 
interchange 

EC  No  Authentication,  Compression,  Encryption 

EE  No  Authentication,  No  Compression,  Encryption 

Security  Originator  Name  M    AN  1/64 

Unique  designation  (identity)  of  the  cryptographic  process  that  performs 
authentication  or  encryption  on  data  to  be  interchanged,  or  originates  a 
cryptographic  service  message 

Note:  X9  has  a  minimum  length  of  4  characters  for  the  security  originator;  no 
mechanism,  or  registration  method  is  provided  by  X9  or  X12  to  guarantee  the 
uniqueness  of  the  identifier 

Security  Recipient  Name  O     AN  1/64 

Unique  designation  (identity)  of  the  cryptographic  process  that  performs 
authentication  or  decryption  on  received  data,  or  is  the  destination  of  a 
cryptographic  service  message 

Note:  X9  has  a  minimum  length  of  4  characters  for  the  security  recipient;  no 
mechanism,  or  registration  method  is  provided  by  X9  or  X12  to  guarantee  the 
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S2S04 


S2S05 


S2S06 
Must  Use  C03101 


C03102 


C03103 

C03104 
C03105 
S2S07 
Must  Use  C03201 


uniqueness  of  the  identifier 

991  Authentication  Key  Name  X     AN  1/64 

Name  of  the  key  used  for  authentication;  this  name  is  mutually  known  to  the 
security  originator  and  the  security  recipient,  is  unique  for  this  relationship, 
and  is  intended  to  allow  the  changing  of  the  key  from  time  to  time 

Note:  The  special  key  name  "0123456789ABCDEF"  is  reserved  for  the 
hexidecimal  value  0123456789ABCDEF  (i.e.  a  fixed  non-secret  value)  to 
provide  a  well-known  value  for  data  integrity  testing  only) 

992  Authentication  Service  Code  X     ID  1/1 
Authentication  options 

4  MD5  Hash 

5  SHA  Hash 

C031      Encryption  Key  Information  X 
Information  needed  to  identify  or  obtain  the  encryption  key 

993  Encryption  Key  Name  M    AN  1/64 

Name  of  the  key  used  for  encryption;  this  name  is  mutually  known  to  the 
security  originator  and  the  security  recipient,  is  unique  for  this  relationship, 
and  is  intended  to  allow  the  changing  of  the  key  from  time  to  time 

Note:  If  any  of  the  optional  fields  are  present,  the  Key  Name  should  contain 
either  "PUBLIC"  if  a  public  key  is  being  used  to  encrypt  the  one-time  key  or 
the  actual  name  of  the  asymmetric  key-encrypting-key  used  to  encrypt  the  one- 
time key. 

1564  Protocol  ID  O     ID  3/3 

Code  specifying  protocol  used  to  encrypt  the  session  key 
KEA  Key  Encryption  Algorithm 

RSA  RSA  Algorithm 

1565  Look-up  Value  O  AN  1/512 
Value  used  to  identify  a  certificate  containing  the  public  key  used  to  encrypt 
the  one-time  key 

1566  Keying  Material  O     AN  1/512 

Additional  material  required  for  decrypting  the  one-time  key 

1567  One-time  Encryption  Key  O  AN  1/512 
Hexadecimally  filtered  encrypted  one-time  key 

C032     Encryption  Service  Information  X 

Information  required  by  the  encryption  operation 

994  Encryption  Service  Code  M    ID  1/3 

Coded  values  representing  options  for  encryption  processing,  including  the  use 
of  compression  and  filtering;  the  code  either  defines  the  encryption  mode  and 
the  transmission  filter  specification  for  filtering  binary  data  into  transmittable 
text  or  specifies  that  the  following  subelements  define  these  values 

2 1  ANSI  X9.23  Cipher  Block  Chaining  (CBC), 
Hexadecimal  Filter 

22  ANSI  X9.23  Cipher  Block  Chaining  (CBC),  ASCII 
Filter 

41  ANSI  X9.23  CFB-8  (Cipher  Feedback),  Hexadecimal 

Filter 
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C03202 


C03203 


C03204 


C03205 
C03206 


C03207 


S2S08 


S2S09 


42  ANSI  X9.23  CFB-8  (Cipher  Feedback),  ASCII  Filter 

1568  Algorithm  ID  O     ID  3/3 
Algorithm  used  for  Encryption 

DE3  Triple  DBA 

DES  Data  Encryption  Standard  (Same  as  DEA) 

As  specified  in  FIPS  46-2. 
SKJ  Skipjack 

1569  Algorithm  Mode  of  Operation  O     ID  3/3 
Mode  of  Operation  of  the  Encryption  Algorithm 

CBC  Cipher  Block  Chaining 

1570  Filter  ID  Code  X     ID  3/3 
Code  specifying  the  type  of  filter  used  to  convert  data  code  values 

ASB  ASCn-Baudot  Filter 

ASC  ASCII  Filter 

HDC  Hexadecimal  Filter 

UUE  Uuencoding 
ZZZ  Mutually  Defined 

Use  to  indicate  Base  64. 
799      Version  Identifier  X     AN  1/30 

Revision  level  of  a  particular  format,  program,  technique  or  algorithm 

1571  Compression  ID  X     ID  3/3 
Type  of  Compression  Used 

913  X9E13  Compression  as  defined  by  X9.32 

ZZZ  Mutually  Defined 

Use  to  indicate  that  each  block  has  been  compressed 
by  using  a  combination  of  the  Lempel-Ziv  LZ77 
algorithm  and  Huffman  coding,  in  accordance  with 
the  Internet  Engineering  Task  Force  (IETF)  Request 
for  Comments  (RFC)  1951  format. 
799      Cite  the  version  of  the  compression  algorithm  cited  in      X     AN  1/30 
S1S07  (C03206)  above. 

Revision  level  of  a  particular  format,  program,  technique  or  algorithm 
Cite  the  version  of  the  compression  algorithm  cited  in  S2S07  (C03206) 
above. 

995  Length  of  Data  X     N  1/18 

Length  of  data  is  the  number  of  character  positions  of  the  compressed  or 
encrypted/filtered  text;  when  data  is  plain  text,  this  field  shall  be  absent 

996  Initialization  Vector  X     AN  16/16 
The  archival  representation  of  a  64-bit  value  expressed  in  hexadecimal 
notation  as  16  ASCII  characters  from  the  set  of  characters  (0..9,  A..F);  the  64- 
bit  value  is  used  as  a  starting  point  for  encryption  of  a  data  sequence  to 
increase  security  by  introducing  cryptographic  variance  and  to  synchronize 
cryptographic  equipment;  a  new  Initialization  Vector  (IV)  shall  be  used  for 
each  message;  the  IV  shall  not  be  intentionally  reused;  the  64-bit  binary  value, 
not  its  ASCII  representation,  is  used  for  the  cryptographic  process;  in  the 
interchange  process,  the  resultant  encrypted  and  filtered  64-bit  IV  is  sent;  the 
hexadecimal  notation  is  the  representation  for  archiving  purposes;  the  IV  shall 
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decrypted  using  the  Electronic  Code  Book  (ECB)  mode  and  the  same  key  used 
to  encrypt  the  message 
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Segment: 

Usage: 
Max  Use: 
Purpose: 
Syntax  Notes: 


S2A 


Assurance  Level  2 


Semantic  Notes: 
Comments: 


Notes: 


Ref. 
Pes. 

Must  Use  S2A01 


Must  Use  S2A02 


Must  Use  C03401 


Optional 
1 

To  allow  for  multiple  assurances  at  the  ST/SE  level 

1  If  C02804  is  present,  then  C02803  is  required. 

2  If  C02806  is  present,  then  C02805  is  required. 

3  If  C02808  is  present,  then  C02807  is  required. 

4  If  C028 10  is  present,  then  C02809  is  required. 

5  If  C02  8 1 2  is  present,  then  C02  8 1 1  is  required. 

6  If  C02  8 1 4  is  present,  then  C02  8 1 3  is  required. 

7  If  C028 1 6  is  present,  then  C028 1 5  is  required. 

8  If  C02818  is  present,  then  C02817  is  required. 

9  If  C02820  is  present,  then  C02819  is  required. 

1  X9  has  a  required  minimum  length  of  four  characters  for  S2A04  (security 
originator).  No  mechanism,  or  registration  method,  is  provided  by  X9  or  X12  to 
guarantee  uniqueness  of  the  identifier. 

2  X9  has  a  required  minimum  length  of  four  characters  for  S2A05  (security  recipient). 
No  mechanism,  or  registration  method,  is  provided  by  X9  or  XI 2  to  guarantee 
uniqueness  of  the  identifier. 

3  The  date/time  stamp  may  determine  which  of  several  key  values  apply,  depending 
on  start  and  expiration  dates  of  different  key  values  that  may  share  the  same 
keyname. 

4  Key  distribution  is  performed  by  other  means  and  thus  only  onetime  keys  are 
allowed  in  S2A09. 

The  use  of  particular  codes  and  corresponding  values  in  S2A09  is  dependent  on  the 
exigencies  of  the  various  crytographic  algorithms. 

1.  Assurance  (Digital  Signature)  segments  (S2A/SVA)  are  not  part  of  the  control 
envelope  structure.  When  used,  insert  the  S2A/SVA  segment pair(s)  immediately 
preceding  the  SE  segment  of  the  transaction  set  for  which  assurance  is  being  provided. 
See  Section  10.5.3  of  the  Federal  Implementation  Guidelines. 

2.  The  S2A  segment  represented  here  is  only  valid  for  versions  3060  and  3070. 

Data  Element  Summary 

Data 
Element 
1432 


Name 


Attributes 
M    ID  3/3 


C034 


1574 


Business  Purpose  of  Assurance 

The  stated  business  purpose  for  appending  the  assurance  to  an  existing 
secured-entity  (whether  functional  group  or  transaction  set);  the  codes 
represent  the  intention  of  the  business  or  application  that  has  control  over  the 
assurance  originator 

ASG  Authorization  Signature  Appropriate  to  this  Document 

CSG  Authorization  Co-signature  Appropriate  to  this 

Document 

Computation  Methods  M 

Algorithms  used  to  calculate  an  assurance 

Assurance  Algorithm  M    ID  3/3 

Code  specifying  the  algorithm  used  to  compute  the  assurance  token 

DSS  Digital  Signature  Standard 

As  specified  in  FIPS 186. 
RSA  RSA 
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Must  Use  C03402 


Must  Use  S2A03 


1575 


1434 


Hashing  Algorithm  M    ID  3/3 

Code  specifying  the  algorithm  used  to  compute  the  assurance  digest 

MD5  MD5 

SHA  Secure  hash  algorithm 

Domain  of  Computation  of  Assurance  Digest  M    ID  1/2 

The  bounds  of  the  text,  whether  contiguous  or  not,  over  which  the  computation 
of  the  Assurance  Token  is  computed  using  the  defined  methodology  of 
computation  and  any  relevant  Assurance  Token  parameters;  the  "body"  is 
either  a  transaction  set  (beginning  with  the  ST  and  including  all  segments  up  to 
the  first  S2A  segment,  but  excluding  any  S2S  segment)  or  functional  group 
(beginning  with  the  GS  and  including  all  transaction  sets  up  to  the  first  SIA 
segment,  but  excluding  any  SIS  segment 


"This  Assurance"  is  defined  as  from  the  "S"  in  SIA  or  S2A  up  to  and 
including  the  data  element  separator  preceeding  the  assurance  digest 


S2A04 


1435 


"Previous  Assurance(s)"  is  defined  as  including  the  entne  SIA  or  S2A 
segment  and  the  entire  SVA  that  follows  the  included  SIA  or  S2A 
Refer  to  003060  Data  Element  Dictionary  for  acceptable  code  values. 
Assurance  Originator  O     AN  1/64 

Unique  designation  (identity)  of  the  cryptographic  process  that  performs  the 
stated  assurance  on  data  to  be  interchanged 


Note:  X9  has  a  required  minimum  length  of  4  characters  for  a  security 
originator;  no  mechanism,  or  registration  method,  is  provided  by  X9  or  X12  to 
guarantee  uniqueness  of  the  identifier 
S2A05  1436      Assurance  Recipient  O     AN  1/64 

Unique  designation  (identity)  of  the  cryptographic  process  that  performs 
validation  of  the  stated  assurance  on  received  data.  In  the  absence  of  an 
Assurance  Recipient  all  potenial  receivers  will  often  be  able  to  validate  the 
assurance  because  the  cryptographic  technique  is  based  on  a  "public"  (as 
opposed  to  "secret")  technology 

Note:  X9  has  required  minimum  length  of  4  characters  for  a  security  recipient; 
no  mechanism,  or  registration  method,  is  provided  by  X9  or  XI 2  to  guarantee 
uniqueness  of  the  identifier 
S2A06  1443      Assurance  Reference  Number  O     AN  1/35 

Alphanumeric  reference  number  issued  by  security  assurance  originator  for  the 
particular  assurance  in  which  it  occurs;  unique  when  used  in  combination  with 
security  originator  data  element 
S2A07  1437      Date/Time  Reference  O     AN  17/25 

Date/time  stamp  in  format  as  follows: 


YYYYMMDDHHNNSSTTTZZZ+XXXX,  where  YYYY  =  4  digit  year  (with 
leading  century),  MM  =  month  of  year  (01. .12),  DD  =  day  of  month  (01. .31), 
HH  =  hour  of  day  in  24-hour  format  (00..23),  NN  =  minutes  of  the  hour  (00- 
59),  SS  =  second  of  hour  (00.. 59),  TTT  =  [optional]  milli-seconds  (000..999), 
ZZZ  =  [optional]  three  character,  nominal  time  zone  indicator  (including 
daylight  savings  time  indicator)  and  XXXXX  =  3-5  digit  (including  leading  + 
or  -  sign)  offset  of  time  to  universal  time,  with  three  position  format  indicating 
hours-offset  for  whole  hours,  and  five  position  format  indicating  hours  and 
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minutes  offset  where  this  is  necessary.  For  example: 


S2A08 


S2A09 

Must  Use  C02801 


Must  Use  C02802 


Not  Used  C02803 
Not  Used  C02804 


Not  Used  C02805 
Not  Used  C02806 


Not  Used  C02807 
Not  Used  C02808 


Not  Used  C02809 


199306152213300CDT+0930  which  represents  15  June  1993,  22:13 
(10:13pm),  Central  Daylight  Time  (Nominal  Value  "CDT"),  in  a  time  zone 
that  is  offset  +  9:30  from  Universal  Time  (Australia) 

1438  Assurance  Text  O     AN  1/64 
Any  text  needed  to  convey  the  name  of  a  signatory,  registration  number, 
certification  number,  or  other  assurance-originator  defined  or  mutually-agreed 
business  text  related  to  the  specific  assurance;  this  text  is  not  defined  for  X12 

'     purposes  and  thus  functions  technically  as  "free  form  text"  though  it  may  have 
structure  that  is  defined  by  the  assurance  originator,  an  industry  group,  a 
governmental  agency,  or  bi-laterally  between  assurance  originator  and 
assurance  recipient 
C028     Assurance  Token  Parameters  O 
Parameters  needed  to  calculate  the  Assurance  Token 

1439  Assurance  Token  Parameter  Code  M    ID  2/2 
A  code  specifying  the  type  of  Assurance  Token  Parameter 

CI  Certification  Authority  ID 

EK  Key  Value  -  One-Time  Key 

KN  Key  Name 

NT  Notarization 

OD  Key-Encrypting-Key  for  One-Time  Key 

UI  User  ID 

1442      Assurance  Token  Parameter  Value  M    AN  1/64 

A  value  of  a  parameter,  usually  specifying  one  or  more  options,  required  for 
the  proper  operation  of  the  cryptographic  algorithm  used  to  compute  the 
Assurance  Token;  depending  on  the  algorithm  used,  one  or  more  values  may 
be  required 

1439      Assurance  Token  Parameter  Code  X     ID  2/2 

A  code  specifying  the  type  of  Assurance  Token  Parameter 

1442     Assurance  Token  Parameter  Value  O     AN  1/64 

A  value  of  a  parameter,  usually  specifying  one  or  more  options,  required  for 
the  proper  operation  of  the  cryptographic  algorithm  used  to  compute  the 
Assurance  Token;  depending  on  the  algorithm  used,  one  or  more  values  may 
be  required 

1439      Assurance  Token  Parameter  Code  X     ID  2/2 

A  code  specifying  the  type  of  Assurance  Token  Parameter 
1442     Assurance  Token  Parameter  Value  O     AN  1/64 

A  value  of  a  parameter,  usually  specifying  one  or  more  options,  required  for 
the  proper  operation  of  the  cryptographic  algorithm  used  to  compute  the 
Assurance  Token;  depending  on  the  algorithm  used,  one  or  more  values  may 
be  required 

1439      Assurance  Token  Parameter  Code  X     ID  2/2 

A  code  specifying  the  type  of  Assurance  Token  Parameter 
1442      Assurance  Token  Parameter  Value  O     AN  1/64 

A  value  of  a  parameter,  usually  specifying  one  or  more  options,  required  for 
the  proper  operation  of  the  cryptographic  algorithm  used  to  compute  the 
Assurance  Token;  depending  on  the  algorithm  used,  one  or  more  values  may 
be  required 

1439      Assurance  Token  Parameter  Code  X     ID  2/2 
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Not  Used  C02810 


Not  Used  C02811 


Not  Used  C02812 


Not  Used  C02813 
Not  Used  C02813 

Not  Used  C02814 


Not  Used  C02815 


Not  Used  C02816 


Not  Used  C02817 


Not  Used  C02818 


Not  Used  C02819 


Not  Used  C02820 


A  code  specifying  the  type  of  Assurance  Token  Parameter 
1442     Assurance  Token  Parameter  Value  O     AN  1/64 

A  value  of  a  parameter,  usually  specifying  one  or  more  options,  required  for 
the  proper  operation  of  the  cryptographic  algorithm  used  to  compute  the 
Assurance  Token;  depending  on  the  algorithm  used,  one  or  more  values  may 
be  required 

1439      Assurance  Token  Parameter  Code  X     ID  2/2 

A  code  specifying  the  type  of  Assurance  Token  Parameter 
1442      Assurance  Token  Parameter  Value  O     AN  1/64 

A  value  of  a  parameter,  usually  specifying  one  or  more  options,  required  for 
the  proper  operation  of  the  cryptographic  algorithm  used  to  compute  the 
Assurance  Token;  depending  on  the  algorithm  used,  one  or  more  values  may 
be  required 

1439      Assurance  Token  Parameter  Code  X     ID  2/2 

1439     Assurance  Token  Parameter  Code  X     ID  2/2 

A  code  specifying  the  type  of  Assurance  Token  Parameter 
1442      Assurance  Token  Parameter  Value  O     AN  1/64 

A  value  of  a  parameter,  usually  specifying  one  or  more  options,  required  for 
the  proper  operation  of  the  cryptographic  algorithm  used  to  compute  the 
Assurance  Token;  depending  on  the  algorithm  used,  one  or  more  values  may 
be  required 

1439     Assurance  Token  Parameter  Code  X     ID  2/2 

A  code  specifying  the  type  of  Assurance  Token  Parameter 

1442      Assurance  Token  Parameter  Value  O     AN  1/64 

A  value  of  a  parameter,  usually  specifying  one  or  more  options,  required  for 
the  proper  operation  of  the  cryptographic  algorithm  used  to  compute  the 
Assurance  Token;  depending  on  the  algorithm  used,  one  or  more  values  may 
be  required 

Assurance  Token  Parameter  Code  X     ID  2/2 

A  code  specifying  the  type  of  Assurance  Token  Parameter 
Refer  to  003060  Data  Element  Dictionary  for  acceptable  code  values. 
Assurance  Token  Parameter  Value  O     AN  1/64 

A  value  of  a  parameter,  usually  specifying  one  or  more  options,  required  for 
the  proper  operation  of  the  cryptographic  algorithm  used  to  compute  the 
Assurance  Token;  depending  on  the  algorithm  used,  one  or  more  values  may 
be  required 

1439      Assurance  Token  Parameter  Code  X     ID  2/2 

A  code  specifying  the  type  of  Assurance  Token  Parameter 
1442      Assurance  Token  Parameter  Value  O     AN  1/64 

A  value  of  a  parameter,  usually  specifying  one  or  more  options,  required  for 
the  proper  operation  of  the  cryptographic  algorithm  used  to  compute  the 
Assurance  Token;  depending  on  the  algorithm  used,  one  or  more  values  may 
be  required 

S2A10  1440      Assurance  Digest  O     AN  1/512 

The  result  of  the  application  of  the  hash  defined  in  the  methodology  expressed 
in  ASCII-hex  notation 


1439 


1442 
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Segment: 

Usage: 
Max  Use: 
Purpose: 
Syntax  Notes: 
Semantic  Notes: 
Comments: 
Notes: 


Must  Use 


Ref. 
Pes. 
SVAOl 


Must  Use  SVA02 


Must  Use  SVA03 


Must  Use  C03301 


Must  Use  C03302 


SVA  Security  Value 

Optional 
1 

To  provide  the  encoded  output  of  a  cryptographic  algorithm 


1.  Assurance  (Digital  Signature)  segments  (S2A/SVA)  are  not  part  of  the  control 
envelope  structure.  When  used,  insert  the  S2A/SVA  segment pair(s)  immediately 
preceding  the  SE  segment  of  the  transaction  set  for  which  assurance  is  being  provided. 
iSee  Section  10.5.3  of  the  Federal  Implementation  Guidelines. 

0.  The  SVA  segment  represented  here  is  only  valid  for  versions  3060  and  3070. 


Data 
Element 
1570 


799 


C033 


1572 


1573 


Data  Element  Summary 

Name  Attributes 
Filter  ID  Code  M    ID  3/3 

Code  specifying  the  type  of  filter  used  to  convert  data  code  values 

ASB  ASCII-Baudot  Filter 

ASC  ASCII  Filter 

HDC  Hexadecimal  Filter 

UUE  Uuencoding 

ZZZ  Mutually  Defined 

l/se  to  indicate  Base  64. 
Version  Identifier  M    AN  1/30 

Revision  level  of  a  particular  format,  program,  technique  or  algorithm 
Security  Value  M 
Value  of  the  Security  Token 

Security  Value  Qualifier  M    ID  3/3 

Type  of  Security  Value 

ASV  Assurance  Token 

CRT  Certificate 

Only  for  use  in  the  3070  version  of  this  segment. 
PUB  Public  Key 

Only  for  use  in  the  3070  version  of  this  segment. 
Encoded  Security  Value  M    AN  1/10E16 

Encoded  representation  of  the  Security  Value  specified  by  the  Security  Value 
Qualifier 
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Segment: 
Usage: 


Security  Trailer  Level  2 

Optional 


Max  Use: 
Purpose: 


To  end  a  secured  area  and  to  provide  the  value  of  cryptographically  computed 
authentication  codes 


Syntax  Notes: 
Semantic  Notes: 
Comments: 
Notes: 


The  S2E  segment  represented  here  is  valid  for  versions  3040,  3050,  3060  and  3070. 


Data  Element  Summary 


Ref. 
Pes. 

Must  Use  S2E01 


Data 
Element 
997 


Name 

Hash  or  Authentication  Code 


Attributes 
M    AN  1/64 


The  message  authentication  code  or  hash/digest  generated  by  the 
authentication  process;  v^^hen  the  Data  Encryption  Standard  (DES)  algorithm  is 
used,  the  field  consists  of  4  hexadecimal  coded  characters  (i.e.,  characters  from 
the  set  0..9,  A..F),  a  separator  character  (space,       or  other),  and  4 
hexadecimally  coded  characters;  when  non-DES  hashes  are  used,  the  result  of 
the  hash  is  expressed  as  hexadecimally  coded  characters  without  spaces;  when 
authentication  or  hash  is  not  used,  this  field  should  be  filled  with  a  non-blank 
character  other  than  the  set  (0..9,  A..F)  for  the  minimum  length 
Enter  the  character  "Z". 
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Segment: 

Usage: 
Max  Use: 
Purpose: 
Syntax  Notes: 


SIA 


Assurance  Level  1 


Semantic  Notes: 
Comments: 


Notes: 


Ref. 
Pes. 

Must  Use  SlAOl 


Must  Use  S1A02 


Must  Use  C03401 


Optional 
1 

To  allow  for  multiple  assurances  at  the  GS/GE  level 

1  If  C02804  is  present,  then  C02803  is  required. 

2  If  C02806  is  present,  then  C02805  is  required. 

3  If  C02808  is  present,  then  C02807  is  required. 

4  If  C02810  is  present,  then  C02809  is  required. 

5  If  C02812  is  present,  then  C0281 1  is  required. 

6  If  C02  8 1 4  IS  present,  then  C02  8 1 3  is  required. 

7  If  C028 1 6  is  present,  then  C028 1 5  is  required. 

8  If  C02  8 1 8  is  present,  then  C02  8 1 7  is  required. 

9  If  C02820  is  present,  then  C028 19  is  required. 

1  X9  has  a  required  minimum  length  of  four  characters  for  S1A04  (security 
originator).  No  mechanism,  or  registration  method,  is  provided  by  X9  or  X12  to 
guarantee  uniqueness  of  the  identifier. 

2  X9  has  a  required  minimum  length  of  four  characters  for  SI  AOS  (security  recipient). 
No  mechanism,  or  registration  method,  is  provided  by  X9  or  XI 2  to  guarantee 
uniqueness  of  the  identifier. 

3  The  date/time  stamp  may  determine  which  of  several  key  values  apply,  depending 
on  start  and  expiration  dates  of  different  key  values  that  may  share  the  same 
keyname. 

4  Key  distribution  is  performed  by  other  means  and  thus  only  onetime  keys  are 
allowed  in  SI A09. 

The  use  of  particular  codes  and  corresponding  values  in  S1A09  is  dependent  on  the 
exigencies  of  the  various  cryptographic  algorithms. 

1.  Assurance  (Digital  Signature)  segments  (SIA/SVA)  are  not  part  of  the  control 
mvelope  structure.  When  used,  insert  the  SIA/SVA  segment pair(s)  immediately 
preceding  the  GE  segment  of  the  group  for  which  assurance  is  being  provided.  See 
Section  10.5.3  of  the  Federal  Implementation  Guidelines. 

2.  The  SIA  segment  represented  here  is  only  valid  for  versions  3060  and  3070.. 

Data  Element  Summary 

Data 
Element 
1432 


Name 


Attributes 
M    ID  3/3 


C034 


1574 


Business  Purpose  of  Assurance 

The  stated  business  purpose  for  appending  the  assurance  to  an  existing 
secured-entity  (whether  functional  group  or  transaction  set);  the  codes 
represent  the  intention  of  the  business  or  application  that  has  control  over  the 
assurance  originator 

ASG  Authorization  Signature  Appropriate  to  this  Document 

CSG  Authorization  Co-signature  Appropriate  to  this 

Document 

Computation  Methods  M 

Algorithms  used  to  calculate  an  assurance 

Assurance  Algorithm  M    ID  3/3 

Code  specifying  the  algorithm  used  to  compute  the  assurance  token 
DSS  Digital  Signature  Standard 

As  specified  in  FIPS 186. 
RSA  RSA 
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Must  Use  C03402 


Must  Use  S1A03 


S1A04 


S1A05 


S1A06 


S1A07 


1575     Hashing  Algorithm  M    ID  3/3 

Code  specifying  the  algorithm  used  to  compute  the  assurance  digest 
MD5  MD5 
SHA  Secure  hash  algorithm 

1434  Domain  of  Computation  of  Assurance  Digest  M    ID  1/2 

The  bounds  of  the  text,  whether  contiguous  or  not,  over  which  the  computation 
of  the  Assurance  Token  is  computed  using  the  defined  methodology  of 
computation  and  any  relevant  Assurance  Token  parameters;  the  "body"  is 
either  a  transaction  set  (beginning  with  the  ST  and  including  all  segments  up  to 
the  first  S2A  segment,  but  excluding  any  S2S  segment)  or  functional  group 
(beginning  with  the  GS  and  including  all  transaction  sets  up  to  the  first  SI  A 
segment,  but  excluding  any  SIS  segment 

"This  Assurance"  is  defined  as  from  the  "S"  in  SI  A  or  S2A  up  to  and 
including  the  data  element  separator  preceeding  the  assurance  digest 

"Previous  Assurance(s)"  is  defined  as  including  the  entire  SIA  or  S2A 
segment  and  the  entire  SVA  that  follows  the  included  SIA  or  S2A 
Refer  to  003060  or  003070  Data  Element  Dictionary,  as  applicable,  for 
acceptable  code  values. 

1435  Assurance  Originator  O     AN  1/64 
Unique  designation  (identity)  of  the  cryptographic  process  that  performs  the 
stated  assurance  on  data  to  be  interchanged 

Note:  X9  has  a  required  minimum  length  of  4  characters  for  a  security 
originator;  no  mechanism,  or  registration  method,  is  provided  by  X9  or  X12  to 
guarantee  uniqueness  of  the  identifier 

1436  Assurance  Recipient  O     AN  1/64 
Unique  designation  (identity)  of  the  cryptographic  process  that  performs 
validation  of  the  stated  assurance  on  received  data.  In  the  absence  of  an 
Assurance  Recipient  all  potential  receivers  will  often  be  able  to  validate  the 
assurance  because  the  cryptographic  technique  is  based  on  a  "public"  (as 
opposed  to  "secret")  technology 

Note:  X9  has  required  minimum  length  of  4  characters  for  a  security  recipient; 
no  mechanism,  or  registration  method,  is  provided  by  X9  or  XI 2  to  guarantee 
uniqueness  of  the  identifier 
1443     Assurance  Reference  Number  O     AN  1/35 

Alphanumeric  reference  number  issued  by  security  assurance  originator  for  the 
particular  assurance  in  which  it  occurs;  unique  when  used  in  combination  with 
security  originator  data  element 

1437  Date/Time  Reference  O     AN  17/25 
Date/time  stamp  in  format  as  follows: 

YYYYMMDDHHNNSSTTTZZZ+XXXX,  where  YYYY  =  4  digit  year  (with 
leading  century),  MM  =  month  of  year  (01..  12),  DD  =  day  of  month  (01.. 31), 
HH  =  hour  of  day  in  24-hour  format  (00.. 23),  NN  =  minutes  of  the  hour  (00- 
59),  SS  =  second  of  hour  (00..59),  TTT  =  [optional]  milli-seconds  (000..999), 
ZZZ  =  [optional]  three  character,  nominal  time  zone  indicator  (including 
daylight  savings  time  indicator)  and  XXXXX  =  3-5  digit  (including  leading  + 
or  -  sign)  offset  of  time  to  universal  time,  with  three  position  format  indicating 
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S1A08 


1438 


S1A09 
Must  Use  C02801 


C028 
1439 


Must  Use  C02802 


1442 


Not  Used  C02803 
Not  Used  C02804 


1439 
1442 


Not  Used  C02805 
Not  Used  C02806 


1439 
1442 


Not  Used  C02807 
Not  Used  C02808 


1439 
1442 


hours-offset  for  whole  hours,  and  five  position  format  indicating  hours  and 
minutes  offset  where  this  is  necessary.  For  example: 

199306152213300CDT+0930  which  represents  15  June  1993,  22:13 
(10:13pm),  Central  Daylight  Time  (Nominal  Value  "CDT"),  in  a  timezone  that 
is  offset  +  9:30  from  Universal  Time  (Australia) 

Assurance  Text  O     AN  1/64 

Any  text  needed  to  convey  the  name  of  a  signatory,  registration  number, 
certification  number,  or  other  assurance-originator  defined  or  mutually-agreed 
business  text  related  to  the  specific  assurance;  this  text  is  not  defined  for  X12 
purposes  and  thus  functions  technically  as  "free  form  text"  though  it  may  have 
structure  that  is  defined  by  the  assurance  originator,  an  industry  group,  a 
governmental  agency,  or  bi-laterally  between  assurance  originator  and 
assurance  recipient 

Assurance  Token  Parameters  O 

Parameters  needed  to  calculate  the  Assurance  Token 


Assurance  Token  Parameter  Code  M 

A  code  specifying  the  type  of  Assurance  Token  Parameter 
CI  Certification  Authority  ID 

EK  Key  Value  -  One-Time  Key 

KN  Key  Name 

NT  Notarization 


ID  2/2 


OD 

UI 


Key-Encrypting-Key  for  One-Time  Key 
User  ID 


Assurance  Token  Parameter  Value  M    AN  1/64 

A  value  of  a  parameter,  usually  specifying  one  or  more  options,  required  for 
the  proper  operation  of  the  cryptographic  algorithm  used  to  compute  the 
Assurance  Token;  depending  on  the  algorithm  used,  one  or  more  values  may 
be  required 

Assurance  Token  Parameter  Code  X     ID  2/2 

A  code  specifying  the  type  of  Assurance  Token  Parameter 
Assurance  Token  Parameter  Value  O     AN  1/64 

A  value  of  a  parameter,  usually  specifying  one  or  more  options,  required  for 
the  proper  operation  of  the  cryptographic  algorithm  used  to  compute  the 
Assurance  Token;  depending  on  the  algorithm  used,  one  or  more  values  may 
be  required 

Assurance  Token  Parameter  Code  X     ID  2/2 

A  code  specifying  the  type  of  Assurance  Token  Parameter 
Assurance  Token  Parameter  Value  O     AN  1/64 

A  value  of  a  parameter,  usually  specifying  one  or  more  options,  required  for 
the  proper  operation  of  the  cryptographic  algorithm  used  to  compute  the 
Assurance  Token;  depending  on  the  algorithm  used,  one  or  more  values  may 
be  required 

Assurance  Token  Parameter  Code  X     ID  2/2 

A  code  specifying  the  type  of  Assurance  Token  Parameter 

Assurance  Token  Parameter  Value  O     AN  1/64 

A  value  of  a  parameter,  usually  specifying  one  or  more  options,  required  for 
the  proper  operation  of  the  cryptographic  algorithm  used  to  compute  the 
Assurance  Token;  depending  on  the  algorithm  used,  one  or  more  values  may 
be  required 
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Not  Used    C02809  1439      Assurance  Token  Parameter  Code  X     ID  2/2 

A  code  specifying  the  type  of  Assurance  Token  Parameter 
Not  Used    C02810  1442      Assurance  Token  Parameter  Value  O     AN  1/64 

A  value  of  a  parameter,  usually  specifying  one  or  more  options,  required  for 
the  proper  operation  of  the  cryptographic  algorithm  used  to  compute  the 
Assurance  Token;  depending  on  the  algorithm  used,  one  or  more  values  may 
be  required 

Not  Used    C02811  1439      Assurance  Token  Parameter  Code  X     ID  2/2 

A  code  specifying  the  type  of  Assurance  Token  Parameter 
Not  Used    C02812  1442      Assurance  Token  Parameter  Value  O     AN  1/64 

A  value  of  a  parameter,  usually  specifying  one  or  more  options,  required  for 
the  proper  operation  of  the  cryptographic  algorithm  used  to  compute  the 
Assurance  Token;  depending  on  the  algorithm  used,  one  or  more  values  may 
be  required 

Not  Used    C02813  1439      Assurance  Token  Parameter  Code  X     ID  2/2 

A  code  specifying  the  type  of  Assurance  Token  Parameter 

Not  Used    C02814  1442      Assurance  Token  Parameter  Value  O     AN  1/64 

A  value  of  a  parameter,  usually  specifying  one  or  more  options,  required  for 
the  proper  operation  of  the  cryptographic  algorithm  used  to  compute  the 
Assurance  Token;  depending  on  the  algorithm  used,  one  or  more  values  may 
be  required 

Not  Used    C02815  1439     Assurance  Token  Parameter  Code  X     ID  2/2 

A  code  specifying  the  type  of  Assurance  Token  Parameter 
Not  Used    C02816  1442      Assurance  Token  Parameter  Value  O     AN  1/64 

A  value  of  a  parameter,  usually  specifying  one  or  more  options,  required  for 
the  proper  operation  of  the  cryptographic  algorithm  used  to  compute  the 
Assurance  Token;  depending  on  the  algorithm  used,  one  or  more  values  may 
be  required 

Not  Used    C02817  1439     Assurance  Token  Parameter  Code  X     ID  2/2 

A  code  specifying  the  type  of  Assurance  Token  Parameter 
Not  Used    C02818  1442      Assurance  Token  Parameter  Value  O     AN  1/64 

A  value  of  a  parameter,  usually  specifying  one  or  more  options,  required  for 
the  proper  operation  of  the  cryptographic  algorithm  used  to  compute  the 
Assurance  Token;  depending  on  the  algorithm  used,  one  or  more  values  may 
be  required 

Not  Used    C02819  1439      Assurance  Token  Parameter  Code  X     ID  2/2 

A  code  specifying  the  type  of  Assurance  Token  Parameter 
Not  Used    C02820  1442      Assurance  Token  Parameter  Value  O     AN  1/64 

A  value  of  a  parameter,  usually  specifying  one  or  more  options,  required  for 
the  proper  operation  of  the  cryptographic  algorithm  used  to  compute  the 
Assurance  Token;  depending  on  the  algorithm  used,  one  or  more  values  may 
be  required 

SIAIO  1440      Assurance  Digest  O     AN  1/512 

The  result  of  the  application  of  the  hash  defined  in  the  methodology  expressed 
in  ASCII-hex  notation 
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Segment: 

Usage: 
Max  Use: 
Purpose: 
Syntax  Notes: 
Semantic  Notes: 
Comments: 
Notes: 


SVA  Security  Value 


Ref. 
Pes. 

Must  Use  SVAOl 


Must  Use  SVA02 


Must  Use  SVA03 


Must  Use  C03301 


Must  Use  C03302 


Optional 
1 

To  provide  the  encoded  output  of  a  cryptographic  algorithm 


1.  Assurance  (Digital  Signature)  segments  (SIA/SVA)  are  not  part  of  the  control 
envelope  structure.  When  used,  insert  the  SIA/SVA  segment  pair(s)  immediately 
preceding  the  GE  segment  of  the  transaction  set  for  which  assurance  is  being  provided. 
See  Section  10.5.3  of  the  Federal  Implementation  Guidelines. 

2.  The  SVA  segment  represented  here  is  only  valid  for  versions  3060  and  3070. 


Data 
Element 
1570 


799 


C033 


1572 


1573 


Data  Element  Summary 

Name  Attributes 
Filter  ID  Code  M    ID  3/3 

Code  specifying  the  type  of  filter  used  to  convert  data  code  values 

ASB  ASCII-Baudot  Filter 

ASC  ASCII  Filter 

HDC  Hexadecimal  Filter 

UUE  Uuencoding 

ZZZ  Mutually  Defined 

Use  to  indicate  Base  64. 
Version  Identifier  M    AN  1/30 

Revision  level  of  a  particular  format,  program,  technique  or  algorithm 

Security  Value  M 

Value  of  the  Security  Token 

Security  Value  Qualifier  M    ID  3/3 

Type  of  Security  Value 

ASV  Assurance  Token 

CRT  Certificate 

pnlyfor  use  in  the  3070  version  of  this  segment. 
PUB  Public  Key 

Only  for  use  in  the  3070  version  of  this  segment 
Encoded  Security  Value  M    AN  1/10E16 

Encoded  representation  of  the  Security  Value  specified  by  the  Security  Value 
Qualifier 
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Segment: 
Usage: 


Security  Trailer  Level  1 

Optional 


Max  Use: 
Purpose: 


To  end  a  secured  area  and  to  provide  the  value  of  cryptographically  computed 
authentication  codes 


Syntax  Notes: 
Semantic  Notes: 
Comments: 
Notes: 


The  SIE  segment  represented  here  is  valid  for  versions  3040,  3050,  3060  and  3070. 


Data  Element  Summary 


Ref. 
Pes. 

Must  Use  SlEOl 


Data 
Element 
997 


Name 

Hash  or  Authentication  Code 


Attributes 
M    AN  1/64 


The  message  authentication  code  or  hash/digest  generated  by  the 
authentication  process;  when  the  Data  Encryption  Standard  (DES)  algorithm  is 
used,  the  field  consists  of  4  hexadecimal  coded  characters  (i.e.,  characters  from 
the  set  0..9,  A..F),  a  separator  character  (space,       or  other),  and  4 
hexadecimally  coded  characters;  when  non-DES  hashes  are  used,  the  result  of 
the  hash  is  expressed  as  hexadecimally  coded  characters  without  spaces;  when 
authentication  or  hash  is  not  used,  this  field  should  be  filled  with  a  non-blank 
character  other  than  the  set  (0..9,  A..F)  for  the  minimum  length 
JEnter  the  character  "Z". 
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Segment: 

Usage: 
Max  Use: 
Purpose: 
Syntax  Notes: 
Semantic  Notes: 


GE  Functional  Group  Trailer 

Mandatory 
1 

To  indicate  the  end  of  a  fimctional  group  and  to  provide  control  information 


1 


Comments:  1 


The  data  interchange  control  number  GE02  in  this  trailer  must  be  identical  to  the 
same  data  element  in  the  associated  functional  group  header,  GS06. 
The  use  of  identical  data  interchange  control  numbers  in  the  associated  functional 
group  header  and  trailer  is  designed  to  maximize  functional  group  integrity.  The 
control  number  is  the  same  as  that  used  in  the  corresponding  header. 


Must  Use 


Ref. 
Pes. 
GEOl 


Must  Use  GE02 


Data 
Element 
97 


28 


Data  Element  Summary 

Name  Attributes 
Number  of  Transaction  Sets  Included  M    NO  1/6 

Total  number  of  transaction  sets  included  in  the  functional  group  or 
interchange  (transmission)  group  terminated  by  the  trailer  containing  this  data 
element 

L  Use  to  identify  the  number  of  ST  segments  (transactions)  within  a 
functional  group. 

2.  Transmit  the  required  number  of  characters  without  leading  or  trailing 
blanks. 

Group  Control  Number  M    NO  1/9 

Assigned  number  originated  and  maintained  by  the  sender 

Cite  the  same  group  control  number  as  was  assigned  by  the  originator  in 

GS06. 
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Segment: 

Usage: 
Max  Use: 
Purpose: 

Syntax  Notes: 
Semantic  Notes: 
Comments: 


lEA  Interchange  Control  Trailer 

Mandatory 
1 

To  define  the  end  of  an  interchange  of  zero  or  more  functional  groups  and  interchange- 
related  control  segments 


Must  Use 


Ref. 
Pes. 
lEAOl 


Must  Use  IEA02 


Data 
Element 
116 


112 


Data  Element  Summary 

Name  Attributes 
Number  of  Included  Functional  Groups  M    NO  1/5 

A  count  of  the  number  of  fiinctional  groups  included  in  an  interchange 

1.  Use  to  identify  the  number  of  GS  segments  (functional  groups)  within  an 
interchange. 

2,  Transmit  the  required  number  of  characters  without  leading  or  trailing 

blanks.  .  „  -,^.^„.;.^,w,t«,tf„  

Interchange  Control  Number  M    NO  9/9 

A  control  number  assigned  by  the  interchange  sender 

Cite  the  same  nine^digit  interchange  control  number  as  was  assigned  by  the 
miginator  in  ISA13. 
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Technical  Publications 


Periodical 


Journal  of  Research  of  the  National  Institute  of  Standards  and  Technology — Reports  NIST  research 
and  development  in  those  disciplines  of  the  physical  and  engineering  sciences  in  which  the  Institute  is 
active.  These  include  physics,  chemistry,  engineering,  mathematics,  and  computer  sciences.  Papers  cover  a 
broad  range  of  subjects,  with  major  emphasis  on  measurement  methodology  and  the  basic  technology 
underlying  standardization.  Also  included  from  time  to  time  are  survey  articles  on  topics  closely  related  to 
the  Institute's  technical  and  scientific  programs.  Issued  six  times  a  year. 

Nonperiodicals 


Monographs — Major  contributions  to  the  technical  literature  on  various  subjects  related  to  the 
Institute's  scientific  and  technical  activities. 

Handbooks — Recommended  codes  of  engineering  and  industrial  practice  (including  safety  codes)  devel- 
oped in  cooperation  with  interested  industries,  professional  organizations,  and  regulatory  bodies. 
Special  Publications — Include  proceedings  of  conferences  sponsored  by  NIST,  NIST  annual  reports,  and 
other  special  publications  appropriate  to  this  grouping  such  as  wall  charts,  pocket  cards,  and  bibliographies. 

National  Standard  Reference  Data  Series — Provides  quantitative  data  on  the  physical  and  chemical 
properties  of  materials,  compiled  from  the  world's  literature  and  critically  evaluated.  Developed  under  a 
worldwide  program  coordinated  by  NIST  under  the  authority  of  the  National  Standard  Data  Act  (Public 
Law  90-396).  NOTE:  The  Journal  of  Physical  and  Chemical  Reference  Data  (JPCRD)  is  published 
bimonthly  for  NIST  by  the  American  Chemical  Society  (ACS)  and  the  American  Institute  of  Physics  (AIP). 
Subscriptions,  reprints,  and  supplements  are  available  from  ACS,  1155  Sixteenth  St.,  NW,  Washington,  DC 
20056. 

Building  Science  Series — Disseminates  technical  information  developed  at  the  Institute  on  building 
materials,  components,  systems,  and  whole  structures.  The  series  presents  research  results,  test  methods,  and 
performance  criteria  related  to  the  structural  and  environmental  functions  and  the  durability  and  safety 
characteristics  of  building  elements  and  systems. 

Technical  Notes — Studies  or  reports  which  are  complete  in  themselves  but  restrictive  in  their  treatment  of 
a  subject.  Analogous  to  monographs  but  not  so  comprehensive  in  scope  or  definitive  in  treatment  of  the 
subject  area.  Often  serve  as  a  vehicle  for  final  reports  of  work  performed  at  NIST  under  the  sponsorship  of 
other  government  agencies. 

Voluntary  Product  Standards — Developed  under  procedures  published  by  the  Department  of  Commerce 
in  Part  10,  Title  15,  of  the  Code  of  Federal  Regulations.  The  standards  establish  nationally  recognized 
requirements  for  products,  and  provide  all  concerned  interests  with  a  basis  for  common  understanding  of 
the  characteristics  of  the  products.  NIST  administers  this  program  in  support  of  the  efforts  of  private-sector 
standardizing  organizations. 

Order  the  following  NIST  publications — FIPS  and  NISTIRs—from  the  National  Technical  Information 
Service,  Springfield,  VA  22161 . 

Federal  Information  Processing  Standards  Publications  (FIPS  PUB) — Publications  in  this  series 
collectively  constitute  the  Federal  Information  Processing  Standards  Register.  The  Register  serves  as  the 
official  source  of  information  in  the  Federal  Government  regarding  standards  issued  by  NIST  pursuant  to 
the  Federal  Property  and  Administrative  Services  Act  of  1949  as  amended.  Public  Law  89-306  (79  Stat. 
1127),  and  as  implemented  by  Executive  Order  1 1717  (38  FR  12315,  dated  May  11,  1973)  and  Part  6  of 
Title  15  CFR  (Code  of  Federal  Regulations). 

NIST  Interagency  Reports  (NISTIR) — A  special  series  of  interim  or  final  reports  on  work  performed  by 
NIST  for  outside  sponsors  (both  government  and  nongovernment).  In  general,  initial  distribution  is  handled 
by  the  sponsor;  public  distribution  is  by  the  National  Technical  Information  Service,  Springfield,  VA  22161, 
ill  paper  copy  or  microfiche  form. 
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